Re: please reivew mobileOK Basic Tests 1.0

I am inclined to change the behavior that is stated, yes. I am
convinced by the example you give Laurens, that it could be a problem,
even if I have never heard of any resource actually delivering XHTML
vs. PNG selectively and expecting the former to work when referenced
via img tag. Still that's a best an argument that it won't matter in
practice, and that the tests will sort of "accidentally" uncover sites
that are trying to do this, which I think should be warned against
actually. Uh oh, maybe there's another debate. So I return to this
argument that this is not going to matter much if at all, and that
where it does, it will in fact highlight problematic behavior (though
it may be inducing it inadvertently, and, this was not something that
was intended originally to be tested as part of mobileOK-ness).

I do think there remains a question of whether this is adjusted now or
later. We've effectively had a version 1.0 out since the start of the
year, and now 1.1, and now 1.2... except 1.0 isn't actually out yet.
*If* this alone would trigger months more of deliberation... we may
simply have to draw a line at what's absolutely necessary to fix and
hold up publication and what is not. But you are right that it may
well not. So let me say I would like to see this adjusted as you
describe and agree there.

On 10/1/07, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Sean Owen schreef:
> > 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.
> >
>
> You have to realise that HTTP is stateless and works on the level of
> individual requests. There is no such thing as indicating what is
> supported by a 'group of requests' as made by the browser. The client
> indicates "media types which are acceptable for the response" (RFC 2616
> section 14.1) in its requests. For requests generated by an <img> tag,
> text/css and application/xhtml+xml clearly aren't.
>
> > 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.)
> >
>
> And the browser can also display all those things. Were the browser only
> able to show PNG images in the body of HTML pages and not stand-alone,
> it would not include image/png in the request header.
>
> > 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.
> >
>
> Of course, the applications of text/css and image/jpg are kind of
> disjunct, so it's not likely a single resource can be represented by
> both of those.
>
> However, an image can be delivered in several versions, e.g. image/jpg,
> or application/xhtml+xml for a version that shows the image with its
> meta-information in HTML and previous/next navigation links, and even
> text/plain for a version containing the text inside the image, or
> converted to ASCII-art. These can all be considered different
> representations of the same resource (and thus, the same URL).
>
> Given this, you could easily arrive in a situation where the <img> tag
> gets the application/xhtml+xml representation because it is listed in
> the Accept header and considered superior by the server (because it is
> more user-friendly), even though it is not an acceptable content type.
>
> I could sketch more situations, but the matter of the fact is that the
> Accept header needs to indicate what content types the request can
> accept, and the system of content negotiation can only work if this is
> indicated correctly. If the Accept header does not contain the correct
> information, then at some point it will cause problems with web sites
> that use that HTTP functionality.
>
> > 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.
> >
>
> Well I raised the issue earlier than today :).
>
> I disagree with the statement that "it's not wrong". It is wrong,
> definitely. However, it will not cause problems on sites that do not use
> content negotiation (because the header is ignored), and on those that
> do, most will probably deal with it in a way that the result coincides
> with what you really want. So if you want to say that this probably
> won't cause problems often, then that would probably be correct
> (although I don't have a crystal ball).
>
> But I still think it should be fixed. I would hate it if even a single
> site would have to remove a nice content negotiation system because
> otherwise they can't get that mobileOK label that management wants.
>
> By the way, I don't know if you should consider this a 'substantive
> change'. Seems more of a bug-fix to me.
>
> Responding to Jo's comments:
> > 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.
> >
>
> A checker can't check for correctness of the response if it sends
> incorrect requests. So it's pretty relevant.
>
> > 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.
> >
>
> It's legal behaviour, given the headers that are sent by the mobileOK
> test, so there is no error in the site's code and thus no reason to
> alarm the site developer by throwing a false error. Or rather, a true
> error, but one in the UA (the test) and not in the site's code.
>
> Now if the test would send the proper Accept headers, and you would get
> a text/css file in return, then yes, that's probably something you'd
> want to know. As I said before, it's good that the test now checks the
> MIME type and content of the response to <img> requests.
>
> Well anyway, I hope I have provided enough explanation to show how HTTP
> functions. Looking forward to this problem getting fixed. I'll keep an
> eye on the specification, and what happens next.
>
>
> Regards,
>
> Laurens Holst
>
> --
> Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Laurens Holst, student, university of Utrecht, the Netherlands.
> Website: www.grauw.nl. Backbase employee; www.backbase.com.
>
>
>

Received on Monday, 1 October 2007 16:46:02 UTC