Yves Lafon
2008-06-04 15:45:11 UTC
Hi,
Here are a few issues/questions about [1]:
General tone of the spec seems targeted at implementors, rather than author=
s.
It would be more readable to have one part dedicated to users, and one part
dedicated to implementors.
In 4:
*
<<<
If stored method case-insensitively matches CONNECT, DELETE, GET, HEAD,=20
OPTIONS POST, PUT, TRACE, or TRACK let stored method be the canonical=20
uppercase form of the matched method name.
TRACK ??? Where is the reference to that?
*
<<
14: If the user argument was not omitted and is not null let stored user=20
be user encoded using the encoding specified in the relevant=20
authentication scheme or UTF-8 if the scheme fails to specify an encoding.
(and same for point 17)
from rfc2617:
To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 [7]
encoded string in the credentials.
basic-credentials =3D base64-user-pass
base64-user-pass =3D <base64 [4] encoding of user-pass,
user-pass =3D userid ":" password
userid =3D *<TEXT excluding ":">
password =3D *TEXT
Userids might be case sensitive.
and from rfc2616:
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].
TEXT =3D <any OCTET except CTLs,
but including LWS>
So UTF8 is not the encoding of choice, there.
*
<<
For security reasons, these steps should be terminated if the header=20
argument case-insensitively matches one of the following headers:
* Accept-Charset
* Accept-Encoding
* Connection
* Content-Length
* Content-Transfer-Encoding
* Date
* Expect
* Host
* Keep-Alive
* Referer
* TE
* Trailer
* Transfer-Encoding
* Upgrade
* Via=20
What is the rationale to add headers and not others ?
Connection ?
Accept-Charset ?=20
For Host, Content-Length, TE... this should be set by the implementation=20
anyway, overriding what a user might fill in, so why terminate the=20
processing here ?
*
<<
Also for security reasons, these steps should be terminated if the start=20
of the header argument case-insensitively matches Proxy- or Sec-.
It would forbid other spec to do something fancy with Proxy-* or Sec-*=20
headers, why ?
* in send()
<<
If the redirect does not violate security (it is same-origin for instance)=
=20
or infinite loop precautions and the scheme is supported transparently=20
follow the redirect and go to the start of this step (step 8).
HTTP places requirements on the user agent regarding the preservation of=20
the request method and entity body during redirects, and also requires=20
users to be notified of certain kinds of automatic redirections.
Why not linking to those requirements ?
*
<<
In case of DNS errors, or other type of network errors, run the following s=
et of steps. This does not include HTTP responses that indicate some type o=
f error, such as HTTP status code 410.
[...]
Some request may be retried, like GET, especially if the targeted web site=
=20
resolves in a set of IP addresses and some of them may be down. It is=20
unclear that the implementation will try its best to process the request,=
=20
by retrying when needed, or if it is forbidden.
Cheers,
[1] http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/
--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.
~~Yves
Here are a few issues/questions about [1]:
General tone of the spec seems targeted at implementors, rather than author=
s.
It would be more readable to have one part dedicated to users, and one part
dedicated to implementors.
In 4:
*
<<<
If stored method case-insensitively matches CONNECT, DELETE, GET, HEAD,=20
OPTIONS POST, PUT, TRACE, or TRACK let stored method be the canonical=20
uppercase form of the matched method name.
TRACK ??? Where is the reference to that?
*
<<
14: If the user argument was not omitted and is not null let stored user=20
be user encoded using the encoding specified in the relevant=20
authentication scheme or UTF-8 if the scheme fails to specify an encoding.
(and same for point 17)
from rfc2617:
To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 [7]
encoded string in the credentials.
basic-credentials =3D base64-user-pass
base64-user-pass =3D <base64 [4] encoding of user-pass,
user-pass =3D userid ":" password
userid =3D *<TEXT excluding ":">
password =3D *TEXT
Userids might be case sensitive.
and from rfc2616:
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].
TEXT =3D <any OCTET except CTLs,
but including LWS>
So UTF8 is not the encoding of choice, there.
*
<<
For security reasons, these steps should be terminated if the header=20
argument case-insensitively matches one of the following headers:
* Accept-Charset
* Accept-Encoding
* Connection
* Content-Length
* Content-Transfer-Encoding
* Date
* Expect
* Host
* Keep-Alive
* Referer
* TE
* Trailer
* Transfer-Encoding
* Upgrade
* Via=20
What is the rationale to add headers and not others ?
Connection ?
Accept-Charset ?=20
For Host, Content-Length, TE... this should be set by the implementation=20
anyway, overriding what a user might fill in, so why terminate the=20
processing here ?
*
<<
Also for security reasons, these steps should be terminated if the start=20
of the header argument case-insensitively matches Proxy- or Sec-.
It would forbid other spec to do something fancy with Proxy-* or Sec-*=20
headers, why ?
* in send()
<<
If the redirect does not violate security (it is same-origin for instance)=
=20
or infinite loop precautions and the scheme is supported transparently=20
follow the redirect and go to the start of this step (step 8).
HTTP places requirements on the user agent regarding the preservation of=20
the request method and entity body during redirects, and also requires=20
users to be notified of certain kinds of automatic redirections.
Why not linking to those requirements ?
*
<<
In case of DNS errors, or other type of network errors, run the following s=
et of steps. This does not include HTTP responses that indicate some type o=
f error, such as HTTP status code 410.
[...]
Some request may be retried, like GET, especially if the targeted web site=
=20
resolves in a set of IP addresses and some of them may be down. It is=20
unclear that the implementation will try its best to process the request,=
=20
by retrying when needed, or if it is forbidden.
Cheers,
[1] http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/
--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.
~~Yves