Add support for sending optional headers with "100 Continue" responses #126

tsg- · 2014-08-23T04:51:08Z

Since WSGI is all about a single response to a single request, in order for servers
to process a PUT as a single request and at the same time pass hints back to the
client (for example, a payload type that the server can accept, or to inform the client
that the server expects to receive payload metadata at the end of the payload
transfer, etc), "100 Continue" response headers is pretty much only place to add
these hints.

This is consistent with RFC2616, section 10.1:

10.1 Informational 1xx

This class of status code indicates a provisional response,
consisting only of the Status-Line and optional headers, and is
terminated by an empty line.

Openstack Swift has an immediate use case for this feature where the object
server will use a "Accept-Payload-Footer: 1" like header to hint the proxy server
to send a payload footer after it has finished sending the payload (for
sending metadata for an encrypted payload, enforcing end-to-end tag checks,
etc).

Details at: https://review.openstack.org/#/c/111562/.

WSGI allows only a single response to a single request. In order for servers to process a PUT as a single request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server that to send a payload footer after it has finished sending the payload (for sending metadata for an encrypted payload, enforcing end-to-end tag checks, etc). Addresses eventlet enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

WSGI allows only a single response to a single request. In order for servers to process a PUT as a single request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server to send a payload footer after it has finished transmitting the payload (for sending metadata for an erasure coded or encrypted payload, enforcing end-to-end Etag checks, etc). Addresses eventlet enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

Since WSGI is all about a single response to a single request, in order for servers to process a PUT as a single HTTP request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server to send a payload footer after it has finished transmitting the payload (for sending metadata for an erasure coded or encrypted payload, enforcing end-to-end Etag checks, etc). Addresses eventlet enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

Since WSGI is all about a single response to a single request, in order for servers to process a PUT as a single HTTP request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: ---------------------------------------------------------- 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. ---------------------------------------------------------- Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server to send a payload footer after it has finished transmitting the payload (for sending metadata for an erasure coded or encrypted payload, enforcing end-to-end Etag checks, etc). Addresses eventlet enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

Since WSGI is all about a single response to a single request, in order for servers to process a PUT as a single HTTP request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: ====================== 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. ====================== Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server to send a payload footer after it has finished transmitting the payload (for sending metadata for an erasure coded or encrypted payload, enforcing end-to-end Etag checks, etc). Addresses eventlet enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

Since WSGI is all about a single response to a single request, in order for servers to process a PUT as a single HTTP request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server to send a payload footer after it has finished transmitting the payload (for sending metadata for an erasure coded or encrypted payload, enforcing end-to-end Etag checks, etc). Addresses eventlet enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

Since WSGI is all about a single response to a single request, in order for servers to process a PUT as a single HTTP request and at the same time pass **hints** back to the client (for example, a payload type that the server can accept, or to inform the client that the server expects to receive payload metadata at the end of the payload transfer, etc), "100 Continue" response headers is pretty much only place to add these hints. This is consistent with **RFC2616, section 10.1**: 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the **Status-Line** and **optional headers**, and is terminated by an empty line. Openstack Swift has an immediate use case for this feature where the object server will use an "Accept-Payload-Footer: 1" like header to hint the proxy server to send a payload footer after it has finished transmitting the payload (for sending metadata for an erasure coded or encrypted payload, enforcing end-to-end Etag checks, etc). Addresses eventlet issue/enhancement eventlet#126 Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>

temoto · 2014-08-26T00:11:12Z

@tsg- your patch was merged and Github automatically closed the pull request. Feel free to reopen it for documentation patch or open a new one.

temoto · 2014-08-27T20:14:03Z

Documentation was merged.

tsg- mentioned this issue Aug 23, 2014

Support optional headers w/ "100 Continue" responses #127

Closed

tsg- mentioned this issue Aug 23, 2014

wsgi: Support optional headers w/ "100 Continue" responses #128

Closed

tsg- mentioned this issue Aug 23, 2014

wsgi: Support optional headers w/ "100 Continue" responses #129

Merged

temoto closed this as completed Aug 27, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for sending optional headers with "100 Continue" responses #126

Add support for sending optional headers with "100 Continue" responses #126

tsg- commented Aug 23, 2014

temoto commented Aug 26, 2014

temoto commented Aug 27, 2014

Add support for sending optional headers with "100 Continue" responses #126

Add support for sending optional headers with "100 Continue" responses #126

Comments

tsg- commented Aug 23, 2014

temoto commented Aug 26, 2014

temoto commented Aug 27, 2014