, and which doesn't need files
with non-ASCII file names: http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/utf8-path.html
, http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/intercept/.htaccess
.
- WBR, Alexey Proskuryakov
formally define - although dead key handling is very similar between
Mac and Windows (and presumably elsewhere), such details may not
remain unchanged forever. It's just that the OS-specific default
handler decides to fire two keypress events in some circumstances, etc.
- WBR, Alexey
this earlier, when there wasn't so much work
put into this diagram, sorry about that.
- WBR, Alexey Proskuryakov
in this regard in the future. However, I am pretty sure that
an official W3C test suite should not flag us with a FAILURE as long
as we conform to the letter of RFC 2616.
- WBR, Alexey Proskuryakov
of
the same differently than another side. For this same reason, there
is no notion of case for HTTP header names, so stating that the case
shouldn't be changed makes no formal sense.
- WBR, Alexey Proskuryakov
should set Accept-Language, but not override one specified by the
author.
- WBR, Alexey Proskuryakov.
the original intent, but for me, it just gives the language
the application is localized to, not the list of languages it sends in
Accept-Language (which is configurable).
- WBR, Alexey Proskuryakov.
for a
temporary XMLHttpRequestException code. My feeling is that interoperability
in this area will take a while to achieve.
- WBR, Alexey Proskuryakov
-R. I
suggest that this behavior is specified in XHR2.
- WBR, Alexey Proskuryakov
() stops to work.
- WBR, Alexey Proskuryakov
2007/7/12, Alexey Proskuryakov [EMAIL PROTECTED]:
However, Firefox and IE only ask the user once, and handle the request as
success with response status 401 if that fails.
Actually, I think I described Firefox/IE behavior incorrectly. I do get
repeated prompts for confirmation
, Firefox and IE only ask the user once, and handle the request as
success with response status 401 if that fails.
Would it make sense to describe Firefox/IE behavior in the spec in this
case?
WebKit bug: http://bugs.webkit.org/show_bug.cgi?id=13075.
- WBR, Alexey Proskuryakov
mentioned, we
will need to special-case text/html in responseXML anyway, so this doesn't
seem to conflict with always parsing local files as XML for now. Here, I'm
assuming that widget authors are unlikely to load XML from .html files.
- WBR, Alexey Proskuryakov
transformations are not appiled to responseXML.
If it is not currently feasible to fully specify the behavior, perhaps a
note mentioning that could be added at least.
- WBR, Alexey Proskuryakov
, inline scripts should not be executed, and XSL
transformations shouldn't be applied.
- WBR, Alexey Proskuryakov
* Anne van Kesteren [EMAIL PROTECTED] [Mon, 04 Jun 2007 16:35:50
+0200]:
On Wed, 30 May 2007 10:40:14 +0200, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
On 5/30/07 12:04 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
It turned out that there is already some code (Dashboard widgets
/HTML decoder.
So you're saying that for responseText you do indeed adhere to the
text/html rules?
Yes, shipping Safari/WebKit does basically that.
- WBR, Alexey Proskuryakov
for Content-Type (which is why I
wanted to terminate detection in step 3 :) ). Maybe this needs to be
mentioned explicitly to reduce confusion.
- WBR, Alexey Proskuryakov.
to do if the
reply is shorter than 4 bytes?) that should only be interesting to
implementors anyway.
- WBR, Alexey Proskuryakov
depending on text/xsl is most likely to be found
among Dashboard widgets.
- WBR, Alexey Proskuryakov.
-Type for string arguments?
Firefox just defaults to application/xml for any data
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsXMLHttpRequest.cpp#1616,
and so do nightly builds of WebKit.
- WBR, Alexey Proskuryakov.
. I guess it would be of little use
with uppercase HTML tags.
- WBR, Alexey Proskuryakov
known formats sounds like a good idea to me.
- WBR, Alexey Proskuryakov
/~ap/webkit/xmlhttprequestenc/001.html and
http://nypop.com/~ap/webkit/xmlhttprequestenc/xmlhttprequestenc.html.
- WBR, Alexey Proskuryakov
, it seems like this is Firefox behavior, but not IE7
one (I could successfully send requests with empty passwords without user
interaction).
Ability to provide empty passwords sounds like a useful bit of
functionality to have.
- WBR, Alexey Proskuryakov
, Alexey Proskuryakov
=11695.
- WBR, Alexey Proskuryakov
documents as UTF-8. Is this something that has been already
discussed, and decided in favor of the new behavior? I'm feeling somewhat
reluctant to break Firefox compatibility (WebKit didn't support xmlEncoding
before, and thus also encoded documents as UTF-8).
- WBR, Alexey Proskuryakov
(actually, Firefox sometimes does that even
for async requests). Was this intentionally omitted from the draft?
- WBR, Alexey Proskuryakov
is required for conformance.
As quoted above, it's a MUST, but then, it is added that browsers MAY not
support it: The usage of userinfo is discouraged MAY not work in
implementations.
- WBR, Alexey Proskuryakov.
that state Open is
followed by an additional pseudo-state with the same numerical value (e.g.,
Safari currently ignores subsequent send() requests).
- WBR, Alexey Proskuryakov
that with a regex like /^name:/mi or some
custom code depending on your needs and tools.
Agreed, but this is not particularly natural or pretty. Unnatural enough
for at least Firefox and Safari to not currently follow this requirement.
- WBR, Alexey Proskuryakov
/nsIXMLHttpRequest.idl#148.
Can the specification be adjusted to match it at this point?
- WBR, Alexey Proskuryakov
33 matches
Mail list logo
