RE: please reivew mobileOK Basic Tests 1.0

I think we could probably bat RFC2616 references back and forth till the
cows come home, so that probably wouldn't be all that productive. 

And I am not actually convinced that "just because existing browsers do
it" is a prima facie case for a checker doing it. We don't after all,
follow meta refresh links etc. 

We do try to fix-up bad markup, but that's not because existing browsers
do it, it's because doing this provides a more useful commentary to the
developer.

So on that theme, the two extremes of outcome from sending headers the
way we suggest are:

a) it makes no difference
b) the server, for whatever reason, turns out to have (e.g.) a css file
that gets served instead of the image for some particular URI.

If you were the developer of the site you'd want to know that. 

Jo



> -----Original Message-----
> From: Sean Owen [mailto:srowen@google.com]
> Sent: 01 October 2007 00:41
> To: Laurens Holst
> Cc: Jo Rabin; mike@w3.org; public-bpwg-comments@w3.org
> Subject: 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 Monday, 1 October 2007 08:11:41 UTC