Re: [Gnu-arch-users] back-building pfs updates

[Florian Weimer]

Aaron Bentley wrote:

> > If a transfer encoding is applied, no Content-Length: header must be
> > sent.

> Here's what the RFC says:
> 
> The transfer-length of a message is the length of the message-body as it
> appears in the message; that is, after any transfer-codings have been
> applied. 
> 
> This looks to me like the content-length may indeed be sent when there's
> an encoding.

There are additional rules in the section describing the Content-Length:
header.

> > You don't want to perform any encoding for plain files anyway.  It just
> > kills server performance.
> 
> Sure, but Arch should not be brittle, either.  If the response is
> encoded, it looks like Arch would do the Wrong Thing.

The length is just advisory.  It doesn't matter much if all lengths are
off by a factor of 4/3 (for base64 encoding).

> > > 3. It appears that for a HEAD request, the content-length is 0.  Can
> > > anyone confirm or deny?
> > 
> > This looks like a server bug (it's a violation of a SHOULD in the RFC).
> 
> In RFC 2616 section 4.4 on Message Length, it says:
> 
> Any response message which "MUST NOT" include a message-body (such as
> the 1xx, 204, and 304 responses and any response to a HEAD request) is
> always terminated by the first empty line after the header fields,
> regardless of the entity-header fields present in the message.
> 
> Doesn't that mean that the Content-length is 0?

No, it specifically means that the answer to a HEAD request may include
a Content-Length: header, even though the message-body is empty.  The
section on the HEAD request clarifies this.