Subject: p2: Content-Length in HEAD responses

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 18:41:01 +1000

p2 4.3.2 says:

    Aside from the payload header fields (Section 3.3), the server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET.

The payload header fields include Content-Length, which in my testing is pretty common in HEAD responses. Was this an oversight, or intentional?

(We already have an exception for HEAD responses in p1's message body length algorithm, section 3.3.3).

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 11:06:47 +0200

On Sat, Apr 20, 2013 at 06:41:01PM +1000, Mark Nottingham wrote:
> p2 4.3.2 says:
> 
>     Aside from the payload header fields (Section 3.3), the server SHOULD
>     send the same header fields in response to a HEAD request as it would
>     have sent if the request had been a GET.
> 
> The payload header fields include Content-Length, which in my testing is
> pretty common in HEAD responses. Was this an oversight, or intentional?

In my opinion it was intentional, as it's the only way for a client
to know the payload size in advance without retrieving the file.

Also I remember about at least one cache which used to truncate cached
contents when a server returned "content-length: 0" in response to a
HEAD request. So most likely, especially due to caches, we don't want
the server to return a different content-length on HEAD as much as
possible.

> algorithm, section 3.3.3).

Exactly, so the SHOULD above should not cause any issue.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 19:11:57 +1000

> to know the payload size in advance without retrieving the file.

I was asking if it was intentional that, as currently specified, we say that C-L should be *omitted* from HEAD responses.

> the server to return a different content-length on HEAD as much as

Yes, I see that quite a bit.

> Exactly, so the SHOULD above should not cause any issue.

At best it's a sloppy SHOULD, but I think it's actively misleading, at the moment... it's saying you SHOULD send the headers back, EXCEPT for a set which includes C-L.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 11:22:54 +0200

On Sat, Apr 20, 2013 at 07:11:57PM +1000, Mark Nottingham wrote:
> I was asking if it was intentional that, as currently specified, we say that
> C-L should be *omitted* from HEAD responses.

This is not what I'm seeing in p1/3.3.2 :

   A server MAY send a Content-Length header field in a response to a
   HEAD request (Section 4.3.2 of [Part2]); a server MUST NOT send
   Content-Length in such a response unless its field-value equals the
   decimal number of octets that would have been sent in the payload
   body of a response if the same request had used the GET method.

Maybe I'm missing something or there are inconsistencies with other parts ?

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 20:01:04 +1000

> Maybe I'm missing something or there are inconsistencies with other parts ?

I think it's an inconsistency between that and <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#HEAD>.

Let's call this editorial and have the editors flip it back to design if they disagree.

---

From: Zhong Yu <[email-masked]>
Date: Sat, 20 Apr 2013 12:20:12 -0500

>     Aside from the payload header fields (Section 3.3), the server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET.

Just to be clear, this sentence *allows* payload headers to be sent, correct?

On the other hand, the wording seems to imply that if a payload header
is sent, it doesn't have to be what it would be if the request had
been a GET.

Does it actually intend to say

    the server SHOULD send the same header fields in response to a
HEAD request as it would have sent if the request had been a GET,
except that the payload header fields can be omitted.

However I don't understand the "except" clause - why not require *all*
header fields to be sent as if they would be for a GET request.

Zhong Yu

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 21 Apr 2013 09:36:15 +1000

> except that the payload header fields can be omitted.

+1  I like that, except that perhaps s/can/MAY/

> header fields to be sent as if they would be for a GET request.

IIRC we allowed that because many implementations don't now, and we don't need to make them non-conformant for interop (since C-L isn't defining the message length in this case).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Apr 2013 13:54:45 +1000

Now:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/452