Re: Defining the meaning of headers associated with a request body

On 19.01.2012 07:57, Zhong Yu wrote:
> The categorization of headers is indeed very confusing; here's my 
> take
> (not an expert)
>
> Content-Length/Transfer-Encoding
>     request and response
>
> Content-Range
>     request and response
>
>     However, HTTP/1.1 only really described it for responses to GET 
> requests.
>     its meaning in other contexts is unclear.
>
> Content-Encoding
>     request and response
>
>     However, there's no official way for client to know what encoding 
> is
>     acceptable by server; a request with Content-Encoding is risky.
>
> Content-Type
>     request and response
>
> ETag
>     response only.
>     (It applies to the representation/entity, not the response)
>

This may make sense opening to PUT requests. Since PUT is based 
semantically around some resource at either client or server end.
POST would seem to have less use since its entity is more ephemeral.

We get a re-occuring question of how to cache POST bodies.

With PUT having ETag and Content-Location middleware could use the 2xx 
response as an indicator that the PUT entity is at Content-Location and 
can work on caching Location+Etag without needing some future backend 
200 response to fetch it first (re-validate would still be needed to get 
the expiry info, but that is small 304).


> Expires
>     response only;
>     and it applies to the response! not the representation/entity.
>
> Last-Modified
>     response only;
>     applies to the representation/entity
>
> Content_Location
>     request and response
>     However, it doesn't seem to be very useful in requests
>
> Content_Language
>     request and response
>     However, usage of Content-Language in requests is not elaborated.
>

Applies to the representation. So is of some small use where there is 
language-specific entity data for at least PUT, POST and WebDAV editing 
extension methods.

>
> So basically, only headers that are appropriate in requests are
> Content-Length/Transfer-Encoding, Content-Type.
>
> Zhong Yu

Received on Wednesday, 18 January 2012 22:46:50 UTC