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

On 31.10.2012 00:15, Dan Winship wrote:
<snip>
>> 3.1. Start Line
>
>>    In theory, a client could receive requests and a server could
>>    receive responses, distinguishing them by their different
>>    start-line formats, but in practice servers are implemented to
>>    only expect a request (a response is interpreted as an unknown or
>>    invalid request method) and clients are implemented to only
>>    expect a response.
>
> This is new text, and given that there will not be an HTTP/1.2, is
> there really any reason to add it?
>

Who says there won't be a 1.2?

I'm pretty sure we will have a revision 1.2 later for mapping some 2.0 
features down to transport over 1.x syntax. There is a short laundry 
list of issues 1.1 still has which can easily be solved, but only by 
incrementing the value to prevent compliance issues.


>
>> 3.2.2. Field Parsing
>
>>    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.

Perhapse this is better written like:
"
   A field value SHOULD be preceded by a single SP;
   however MAY be preceded by optional whitespace (OWS).
"

>
>>        If the actual number of octets sent in the message is more
>>        than the indicated Content-Length
>
> This is impossible by definition; any octets after the indicated
> Content-Length are not part of the message.
>
>>        the recipient MUST only process the message body up to the
>>        field value's number of octets; the remainder of the message
>>        MUST either be discarded or treated as the next message in a
>>        pipeline. For the sake of robustness, a user-agent MAY
>>        attempt to detect and correct such an error in message
>>        framing if it is parsing the response to the last request on
>>        a connection and the connection has been closed by the
>>        server.
>
> As above, "user agent" shouldn't have a hyphen, but it should be
> "client" here anyway, shouldn't it?
>
> Maybe replace the whole paragraph with:
>
>     For the sake of robustness, a client MAY assume that any
>     additional octets after the indicated Content-Length in the
>     response to the last request on a connection were intended to be
>     part of the message body.
>

"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.




>> 6.1. Connection
>
>>    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

>
>>      Connection: close
>>
>>    in either the request or the response header fields indicates 
>> that
>>    the connection SHOULD be closed after the current 
>> request/response
>>    is complete (Section 6.2.5).
>
> Likewise. (6.2.5 seems to agree)

+1 on that being a MUST. That is either a security vulnerability when 
connections are not closed or a waste of resources. Either way closure 
is indicated. If anything is made non-compliant by that MUST they *need* 
to be fixed.

<snip>
>> 6.2.2. Reuse
>
>>    A server MAY assume that an HTTP/1.1 client intends to maintain a
>>    persistent connection until a close connection option is received
>>    in a request.
>
> SHOULD?
>

MUST even I would say. This is only an assumption being discussed. 
Teardown semantics requires coping with unexpected socket closure anyway 
when the assumption is wrong. All this being a MUST would do AFAICT is 
make the servers with broken pipeline implementations non-compliant (a 
Good Thing IMO).


Amos

Received on Tuesday, 30 October 2012 23:09:42 UTC