Re: please reivew mobileOK Basic Tests 1.0

I still don't think this is "wrong" per RFC 2616. The client is
listing content types it knows about and the server is responding with
one of those content types. Sending an image when a stylesheet is
expected is a serious application error, not quite a problem with
Accept.

That said, points well taken. Firefox for example will restrict the
content types it lists when requesting an image (though the initial
request for the page is going to list most everything it understands,
since the URL could resolve to a lot of different things.)

I don't quite get the point about content negotiation -- what's the
situation where a correctly-behaved server does the wrong thing
because some irrelevant types were listed in Accept? Returning an
image for a stylesheet is not an HTTP header problem, though it
wouldn't have hurt if the client reminded the server of that in the
Accept header, sure.

One small issue is that changing this causes a fourth round of last
call comments. As last time the practical argument is "it's not wrong"
and probably matters little, even if it could be improved. It's a moot
point if we are fortunate (?) enough to need more substantive changes
anyway. Otherwise... let's come back and cross this bridge when we get
there.

Sean


On 9/30/07, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Jo Rabin schreef:
> >
> > Laurens
> >
> >
> >
> > Thanks for your further reply on this. Ref RFC2616
> >
> >
> >
> > Accept headers *can* be used to specify certain media
> >
> > types which are acceptable for the response. …
> >
> >
> >
> > Not "should" or "must".
> >
>
> I think you're misinterpreting that sentence, it "can" be used because
> the Accept header is optional. It does not imply the Accept header can
> be used differently than described, and that you can just put any kind
> of nonsense in there and still expect it to work.
>
> > And if the server needs to respond with a 3xx, 4xx or 5xx response
> > code, in principle it would not know how to do that if the request did
> > not contain a range of content types.
> >
>
> I don't understand how that would be. Different content types are just
> different representations of data. A single resource can be represented
> by several content types. If you're going to indicate to the server that
> you accept certain representations, then the server can send any of
> them. However regardless of the content type, the server knows perfectly
> well when a response of 3xx, 4xx or 5xx is needed for that resource
> (e.g. when it has moved or is unavailable). They're two separate things,
> and unrelated.
>
> I do not understand the resistance against just sending the correct
> Accept headers. That is how the protocol is designed, and it's also how
> browsers implement it.
>
> Also, you're completely glossing over my statement that sending
> incorrect Accept headers *breaks* servers which correctly handle content
> negotiation, because the accepted content types are not correctly
> indicated by the test. Thus, with this test the W3C would force web
> sites to not use content negotiation if they want to get your label for
> 'correctness'.
>
>
> ~Grauw

Received on Sunday, 30 September 2007 23:41:03 UTC