Re: WGLC review of p1-messaging (editorial stuff)

On 10/30/2012 07:09 PM, Amos Jeffries wrote:
>>>    A field value MAY be preceded by optional whitespace (OWS); a
>>>    single SP is preferred.
>>
>> "MAY" and "optional" are redundant. "A field value is preceded by
>> optional whitespace..."
>>
> 
> MAY is normative clause though... "optional" is not normative.

The grammar shows OWS there, and the grammar is normative. (Which means
the MAY here contradicts the grammar, since it implies there's "[ OWS ]"
rather than "OWS" there.)


> "detect and correct" does not necessarily mean "extend the
> Content-Length". Doing so is rarely a good idea anyway as it encourages
> servers to send bad Content-Length values when it is unknown length
> response entity and simply indicate Connection:close.
> 
> Squid and other intermediaries will discard the additional octets before
> forwarding. Your change would make that undefined behaviour where today
> it is recognized best practice error correction behaviour.

There doesn't need to be text allowing you to discard the additional
octets, because there wasn't any text that would have allowed you to
include them; once you reach the end of the response, anything after
that is, by definition, not part of the response. So what squid is doing
is already correct without needing the "MUST either be discarded or
treated as the next message in a pipeline" (which wasn't in 2616 anyway).

OTOH, browsers do the opposite, and treat the extra octets as part of
the response, because there are sites that depend on this. And that's
not allowed without some sort of "MAY detect and correct" here, so I
assumed that that was what the new text was about.


>>>    When a header field is used to supply control information for or
>>>    about the current connection, the sender SHOULD list the
>>>    corresponding field-name within the "Connection" header field.
>>
>> Isn't that a MUST?
> 
> No headers defined as hop-by-hop in this base spec are exempt from
> explicit listing in Connection:. It would be redundant octets in the
> message headers. Only headers defined in other specifications which
> recipients may not be compliant with are

Nope. In the changes-from-2616 appendix:

  drop notion of header fields being "hop-by-hop" without being listed
  in the Connection header field.


-- Dan

Received on Wednesday, 31 October 2012 12:21:41 UTC