- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 25 Jan 2012 23:09:41 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>
- CC: ietf-http-wg@w3.org
On 2012-01-25 22:58, Amos Jeffries wrote: > On 26.01.2012 05:00, Julian Reschke wrote: >> FYI: this is a minor update (adding a note about XHR sometimes using >> a different encoding default). At this point there's nothing left to >> do here except for waiting for feedback; hopefully from implementers. >> Should I try to get it published as is? >> > > I have a few questions before going off and looking at implementing :) > (Sorry if I missed a Q about this already.) > > In section 3 you say "UTF-8" is to be case-insensitive. The insensitive > comparison is slower on bytes which need changing. > I assume we should send the exact spec text of upper case (instead of > the popular de-facto lower-case) as a best practice for highest speed > and uniformity of implementations? Dunno. Charsets are usually compared case-insensitively. > I assume this is also not limited to WWW-Authenticate:. But applies > equally to Proxy-Authenticate? I haven't thought about that, but that seems correct. I'll need to add that. > Nit: in appendix A.1 paragraph 2 the word "already" is spread very thick > on the ground and makes the text seem dated. This is the new text right? Ack. Will rephrase. > And what is the second sentence there trying to convey? that some U-A > will violate this spec? > > " > Note that some user > agents already have different defaults depending on whether the > request originates from page navigation as opposed to a script-driven > request using XMLHttpRequest [XHR]. > " Well, it's stating a fact that many readers probably don't know, and which is relevant to the deployment... > IIRC there was wording sprinkled around various RFCs already calling > such implementations "old" or similar to deprecate them and hint at the > text loophole being removed in some future document revision. Best regards, Julian
Received on Wednesday, 25 January 2012 22:10:24 UTC