> From RFC 2616:
> 
> "The HEAD method is identical to GET except that the server MUST NOT
> return a message-body in the response. The metainformation contained in
> the HTTP headers in response to a HEAD request SHOULD be identical to
> the information sent in response to a GET request."

indeed :)

> 
> 
> From RFC 2119:
> 
> "SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course."

yeah, this is the conversation that comes up all the time.  from what I've
seen in various forums, despite this definition SHOULD essentially means
MUST.  at least I haven't come across a circumstance where it hasn't :)

> I think here we've hit a "valid reason in particular circumstance" to
> strip the content-length header.

well, that depends.  but the short of it is that almost nobody is HEAD
compliant (see a recent thread in the past month wrt mozilla and HEAD and
yahoo).  and almost nobody is compliant because almost nobody understands
exactly what a HEAD request is supposed to entail, thus the reason why I was
belaboring the point.  but if you go against the RFC "recommendation"
knowing full well what you are doing, I guess that's ok ;)

> 
> As for the implications, content-length is used for persistent HTTP
> connections but that doesn't happen for HEAD requests - only for GETs.
> Hence there should be no ill side effects by stripping the
> Content-Length metadata for HEAD requests.

actually, I wonder how true that is.  you would certainly think so, but if
you go back to that mozilla thread and read through the bugzilla entries the
mozilla dev guys make it sound as though they are using a HEAD request then
making a series of GETs over the same connection.  but what do I know...

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Reply via email to