Re: [http-state] Conformance classes

[Adam Barth <[e-mail]>]

Daniel,

My understanding of your position is that we should make the entire
cookie protocol (meaning everything the user agent is required to
understand) conforming for servers.  We can then recommend (at the
SHOULD level?) that servers stick to a subset of the protocol that's
easier to understand / has cleaner semantics.

Is that correct?  If so, that seems reasonable to me.

Adam


On Wed, Dec 16, 2009 at 5:51 AM, Daniel Stenberg <[e-mail]> wrote:
> On Tue, 15 Dec 2009, Maciej Stachowiak wrote:
>
>>> Set-Cookie: headers that are using illegal syntaxes should be ignored.
>>
>> Why is "ignore" the only acceptable behavior when processing a
>> nonconforming header field?
>
> Because that's the sane way to treat protocol errors. If we deem another way
> to be the correct way, then the protocol dictates this and then it isn't
> nonconforming anymore.
>
>> Or to turn it around, why must everything with a processing requirement
>> for the recipient other than "ignore" be considered legal to send?
>
> I don't necessarily think that incoming must match outgoing, but if a client
> is supposed to accept incoming Set-Cookie: headers given a certain format,
> then that format is the legal one. If then some cases of accepted headers
> lead to a different action and a different output in subsequent requests,
> then the spec should detail this.
>
>> Surely it can be rational to define error handling other than "ignore" in
>> at least some cases.
>
> Like how? In this case it was not even suggested to be treated as "error
> handling" but simply to pretend that the misformed incoming header is valid
> and then generate an invalid header back and thus produce another
> non-conformant header. That's not my idea of error handling.
>
>> For example, HTML4.01 requires clients to render the contents of unknown
>> elements, even though such elements are a conformance error for the producer
>> of the document.
>
> 1) This is not HTML and I don't think HTML rules or thoughts apply very good
> on httpstate and 2) I'm not sure I even agree that those are good ideas for
> HTML.
>
>> We have here a situation where there are both legacy servers and legacy
>> clients. Sending certain unusual constructs may break some legacy clients.
>
> I think you're turning this into too many shades of grey. While it may be
> hard, I truly believe we will be much better off by clearly specifying what
> is conforming to the spec and what is not. Incoming headers that aren't
> legal can and should be ignored.
>
> If certain bugs (yes I view them as bugs) are significant enough to be
> supported by general clients and servers to make them interoperable to a
> satisfying level, then we make them part of this spec. And then we stop
> viewing them as bugs.
>
> If the bugs are minor enough to not cause a noticable difference, we make
> them remain bugs and they do not make it to the spec. In this category I
> consider the nameless cookies and the requirement on sort order to be.
>
> The greyness here is only where we draw the line and we can argue back and
> forth of what to consider actual practise and what's a bug and so on, but
> inside the spec there should (ideally) be no doubt.
>
>> Thus, it is prudent that new servers not do so.
>
> Isn't that why we use SHOULD and MUST NOT etc in specs?
>
>> The fact that the required syntax to accept is broader than the legal
>> syntax to send is unfortunate, but not fundamentally illogical.
>
> It could indeed be wider, it should just clearly state what the accecept
> syntax is. As well as for the sending one.
>
> --
>
>  / daniel.haxx.se
>