W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sat, 21 Jan 2012 23:51:34 +1300
Message-ID: <4F1A98B6.4020606@treenet.co.nz>
To: ietf-http-wg@w3.org
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 Saturday, 21 January 2012 10:52:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:53 GMT