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
>
------------------------------------------------------------
------------
>
> *From
public-bpwg-comments-request w3.org
> [mailto:public-bpwg-comments-requestw3.org]
*On Behalf Of *Laurens Holst
> *Sent 29
September 2007 19:01
> *To mikew3.org
> *Cc
public-bpwg-commentsw3.org
> *Subject Re: please
reivew mobileOK Basic Tests 1.0
>
>
>
> Hi,
>
> Below are my comments to the resolution:
>
> mikew3.org <mailto:mikew3.org> schreef:
>
> Dear Laurens Holst ,
>
> The Mobile Web Best Practices Working Group has
reviewed the comments you
> sent [1] on the Last Call Working Draft [2] of the W3C
mobileOK Basic
> Tests 1.0 (2nd Last Call) published on 25 May 2007.
Thank you for having
> taken the time to review the document and to send us
comments!
>
> The Working Group's response to your comment is
included below, and has
> been implemented in the new version of the document
available at:
> http://www.w3.org/TR/2007/WD-mobileOK-basic10-test
s-20070928/.
>
> Please review it carefully and let us know if you agree
with it or not
> before 19 October 2007. In case of disagreement, you
are requested to
> provide a specific solution for or a path to a
consensus with the Working
> Group. If such a consensus cannot be achieved, you will
be given the
> opportunity to raise a formal objection which will then
be reviewed by the
> Director during the transition of this document to the
next stage in the
> W3C Recommendation Track.
>
> Thanks,
>
> For the Mobile Web Best Practices Working Group,
> Michael(tm) Smith
> W3C Staff Contact
>
> 1. http://www.w3.
org/mid/4668801F.2090006students.cs.uu.nl
> 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070525/
>
>
> =====
>
> Your comment on 2.3.2 HTTP Request:
>
>> First, section 2.3.2 HTTP Request states:
>>
>>
>>> *
>>>
>>> Include an |Accept| header indicating
that Internet media
>>>
>> types
>>
>>> understood by the default delivery
context are accepted by
>>> sending exactly this header:
>>>
>>> Accept:
>>>
>
application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xh
tml+xml;q=0.1,text/css,image/jpeg,image/gif
>
>>>
>>>
>>>
>> I think this is incorrect, text/css should NOT be
included in the
>> Accept
>> header, and image/jpeg and image/gif ONLY if the UA
is expected to
>> support showing these images independantly of a
document (the mobileOK
>>
>> tests should explicitly check whether this is
supported). The client
>> after all does not know how to handle a text/css
file independently of
>>
>> XML markup.
>>
>> Instead, it should send an "Accept:
text/css" header when the CSS files
>>
>> that are linked using <link
rel="stylesheet">, <?xml-stylesheet?> or
>> include. Similarly, images referenced from
<img> should send an
>> "Accept: image/jpeg,image/gif" header.
Aside from checking the Accept
>> header for the main page, the mobileOK tests should
also check that
>> Accept headers send these values for stylesheet and
image requests.
>>
>
>
> Working Group Resolution:
> We do not think it is wrong to specify the headers in
the way we do,
> however we accept that we do not properly check that
the right sort of
> content has come back in response to the request. In
other words, if the
> request is made because of an img tag then the response
should be an
> image. We did not test for that in the draft you
reviewed and we will
> amend accordingly. In particular, in 3.4, <img>
tags that retrieve valid
> CSS delivered as text/css should for example FAIL too.
>
>
>
> I do not think this is the correct resolution (although
it is good
> that the test now also checks the response).
>
> The reason for this is that in your HTTP request you
say that a file
> can be delivered in all the formats specified by the
Accept header.
> Thus, if the server sends you a text/css file, it can
not lead to FAIL
> because you asked for it.
>
> Quote from the HTTP specification RFC 2616 section
14.1:
>
> The Accept request-header field can be used to specify
certain media
> types which are acceptable for the response. Accept
headers can be
> used to indicate that the request is specifically
limited to a small
> set of desired types, as in the case of a request for
an in-line
> image.
>
>
>
> Checking in the UA (in this case, the test) for whether
something is
> an image and throwing an error, but at the same time
saying in the
> HTTP headers that you *do* accept non-images is
inconsistent and
> incorrect. You are sending false information to the
server. What’s
> worse, sites which *correctly* implement content
negotiation properly
> and e.g. send text/css *according to the request*, will
get a FAIL on
> your test.
>
> The solution you propose breaks content negotiation as
specified in
> RFC 2616 and is not acceptable.
> The solution I provide is to send the following HTTP
header for
> requests resulting from <img> tags: Accept:
image/jpeg,image/gif
> An alternative solution is to not send an Accept header
at all.
>
>
> ----
>
> Your comment on 2.3.2 HTTP Request:
>
>> Third, in that same section, there is a requirement
that only HTTP GET
>> methods can only be used. What about form
submissions with POST?
>> Forcing
>> forms to be sent with the GET method seems
undesirable and impairs the
>>
>> HTTP functionality. It seems a silly limitation
too, because if a
>> mobileOK Basic application must support HTTP and
HTTPS, and Basic and
>> Digest HTTP authentication, then surely support for
POST would be
>> trivial. The mobileOK tests should provide tests
for checking proper
>> cache clearing after a POST request has been done
on a URL.
>>
>
>
> Working Group Resolution:
> We will insert a reference in 2.3.2 referring to 2.3.8
to make it clearer
> that POST is definitely allowed as a form action in
mobileOK content but
> that it is simply not tested, for fear of the tester
causing unwanted side
> effects.
>
>
>
> Great.
>
>
> ----
>
> Your comment on 3.4 CONTENT_FORMAT_SUPPORT and
VALID_MARKUP:
>
>> Fifth, in 3.4 CONTENT_FORMAT_SUPPORT and
VALID_MARKUP it does not
>> distinguish included resources by type, that is, if
it’s a stylesheet
>>
>> include, only the text/css media type should be
accepted (otherwise
>> FAIL), and if it’s an image include, only
image/gif or image/jpeg is
>>
>> accepted and not text/css. If it’s an object
include, unless the UA
>> is
>> expected to support CSS there by showing it
somehow, text/css should
>> also not be accepted.
>>
>
>
> Working Group Resolution:
> We will add that if the resource is expected to be a
stylesheet, it must
> be text/css (and be valid CSS), and likewise for images
and FAIL if it is
> not - also that Objects need to be images in this
case.
>
>
>
> Great.
>
>
> Regards,
>
> ~Grauw
>
> --
> Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Laurens Holst, student, university of Utrecht, the
Netherlands.
> Website: www.grauw.nl <http://www.grauw.nl>.
Backbase employee; www.backbase.com <http://www.backbase.com&
gt;.
--
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.
|
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 <lholststudents.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
|
