Re: please reivew mobileOK Basic Tests 1.0

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.