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

Belated 'thanks-very-much' for this reply, Amos, very much appreciated. :-)

Duncan

> On 20/01/2012 10:36 p.m., Duncan Cragg wrote:
>> Thanks for the replies so far .. lots of very interesting information 
>> in there.
>>
>> My original question remains, however, so I'm wondering if I'm just 
>> missing something about the nature of HTTP headers...
>>
>> Allow me to cut right down to the essentials of my question:
>>
>>  POST /z HTTP/1.1
>>  Cache-Control: max-age=3600
>>  Etag: "1"
>>  Content-Location: http://foo.com/y
>>
>> My question is: /what do those three headers mean/ ??
>>
>
> Cache-Control: max-age=3600    ==> the reply to this POST must not be 
> an object older than 3600 seconds.
>    
> http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-18#section-3.2.1
>
> ETag: "1"   ==> the body object of this request has a unique 
> identifier "1". The new spec does *not* limit it to one of request or 
> reply.
>   
> http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-18#section-2.3
>
> Content-Location: http://foo.com/y   ==> a GET request of this URL 
> would produce identical object for response body as this POST request 
> body.
>    
> http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-18#section-6.7
>
> "  if one were to perform a GET on this URI at the time of
>    this message's generation, then a 200 response would contain the same
>    representation that is enclosed as payload in this message.
>
> "
>
>
>
>> If they mean 'nothing', does that allow me to correctly set up an 
>> agreed protocol wherein they mean 'associated with the POSTed 
>> body/entity'?
>
> Ignoring because you started with "If" and its condition was false.
>
>
>> From combinations of RFC2616 and Bis, I get that:
>>
>
>>  - Cache-Control is/was a 'general header', although registered 
>> alongside the 'entity header', Expires, in p6.
>
> Was. As you note below the definition was dropped. It is about 
> controls on the cache handling. Which implies the response, but is not 
> so limited base on the header name alone. The option values are where 
> scope for particular request/response usage and other things like 
> entity comes into play.
>
>>  - Etag is a 'response header', although registered alongside the 
>> 'entity header', Last-Modified, in p4.
>
> The response limitation has been removed. It simply means the entity 
> representation now. It is a coincidence that most requests have no 
> body entity for it to be useful with today.
>
>>  - Content-Location is/was an 'entity header'.
>
> Still is. see above.
>
>
>>
>> (The phrases 'entity' and 'general' appear to be dropped since ticket 
>> 224.)
>>
>> Perhaps there would be value in constructing a single table with all 
>> the headers, what category they are (request, response, other??), 
>> what they mean in requests (GET/P*), what in responses?
>
> As I understand it the headers have been split into groups along 
> feature boundaries. The groups being:  messaging, semantics, payload 
> (entity/representation), conditional, cache, range, and 
> authentication. Each of the draft document outlines and defines the 
> headers which are in that group, splitting them by request and reply 
> sub-groups and tabularizes the headers as part of the RFC index.
>
> So where would one put a re-joined table? and what use would it be for 
> those who care only about one particular sub-group of headers?
>
>
>>
>> Saying 'in this context, this header means nothing as far as Bis is 
>> concerned, so use it as you like' would be quite valuable information 
>> in general, where it holds true.
>>
>
> The editors have been doing exactly that AFAICS, whenever consensus 
> here found that it was important to state something was useless. Just 
> because we have no use for things *yet*, does not make them 
> permanently meaningless. Also as has been mentioned before writing 
> down everything which is *not* useful is a unimaginably huge amount 
> text to wade through for a few small nuggets about when it *is* useful.
>
> AYJ
>
>

Received on Tuesday, 7 February 2012 23:35:06 UTC