Re: [squid-users] 301 Moved Permanently: bug?

On Friday 12 July 2002 20.34, Florin Andrei wrote:

> > What I am missing in this reply stream is a reply entity
> > following the headers..
>
> What do you mean?

A proper HTTP 301 reply message looks something like

-------------------------------------------------------
HTTP/1.X 301 Moved Permanently
Location: http://the.new.location/
Content-Type: text/html
Content-Length: the-length-in-bytes-of-the-reply-entity
[more headers]

<H1>The document requested has moved to a new location</H1>

<P>The document requested has moved to a new location. Please see it's
<A
HREF="....">new location</A>.
-------------------------------------------------------

The reply-entity is the message after the headers. See RFC2616 section
1.3.2 "301 Moved Permanently", and RFC2616 sections 4, 6 and 7..

To summarise:

A HTTP reply message always consists of two parts

 a) The reply message headers

 b) The reply message entity

This is irregardless of the HTTP status code of the reply. All replies
have a reply entity. (with the exception to replies to HEAD requests
where the reply headers is identical to that of a GET request except
that no reply entity will follow, the exception that makes the rule)

The headers and the entity is separated by a blank line, and the
entity continues for Content-length bytes or if no Content-length
header is given, until the connection is closed. Did not see a
Content-length header in the reply headers you gave so technically
the HTTP message continues until the TCP connection is closed by the
server. Think this explains why I am asking these questions about who
closed the connection when..

A reply entity can be anywhere from 0 to infinity in size, but servers
SHOULD include a descriptive reply entity in all generated messages
to describe the cause of the message (meaning, a 0 sized reply entity
is basically only allowed for GET requests for a 0 sized object...)

Minor note: In HTTP/1.1 there is an alternative delimiting method by
using chunked transfer encoding, but this does not apply when using a
Squid proxy as Squid is a HTTP/1.0 proxy and will downgrade the
request to HTTP/1.0 to ensure a protocol format that is compatible
with HTTP/1.0. The "Use HTTP/1.1" setting of your browser does not
matter at all here. Any user-agent or server sending chunked transfer
encoded messages to Squid is in clear violation of the HTTP/1.1
specification. But please note that chunked transfer encoding was NOT
used in the reply you quoted earlier.

Regards
Henrik
Received on Fri Jul 12 2002 - 18:09:31 MDT