On Fri, 21 Apr 2006 15:58:27 +0200, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
example) would contain a user name and password. I *assume* you're
referring to the userinfo production in RFC3986; e.g.,
http://user:[EMAIL PROTECTED]/path/?query
It may be better to use this terminology
* Anne van Kesteren wrote:
Internet Explorer removed support for illegal HTTP URLs such as the one
you've provided above because it has been abused too much in phishing
mails. For other schemes where this is perfectly valid, like ftp, it
works just fine in Internet Explorer.
What does IE
On Mon, 01 May 2006 19:17:27 +0200, Mark Nottingham [EMAIL PROTECTED]
wrote:
[...]
Well, another way to set these headers is letting the author do it. So
I can see why there's a requirement on UAs here from that perspective...
I was thinking of something like
UAs must not allow the
On Thu, 06 Apr 2006 03:04:53 +0200, Mark Nottingham [EMAIL PROTECTED]
wrote:
Great stuff! A few quick comments on the draft;
* responseText attribute - type the response as an HTTP entity
explicitly (you already do this for the request data); that way, there's
no ambiguity about what
* Mark Nottingham wrote:
example) would contain a user name and password. I *assume* you're
referring to the userinfo production in RFC3986; e.g.,
http://user:[EMAIL PROTECTED]/path/?query
It may be better to use this terminology (userinfo) explicitly,
along with an appropriate reference.
On 2006/04/21, at 6:34 AM, Anne van Kesteren wrote:
* responseText attribute - type the response as an HTTP entity
explicitly (you already do this for the request data); that way,
there's no ambiguity about what level the implementation operates
at. I.e., XHR won't give you direct access
The Referer header MUST be set, and MUST NOT be overridable; once
cross-site XHR is available, sites will want to use it for
security, logging, etc.
I don't agree with this, a user agent MUST be allowed to anonymise
browsing, tracking users is not a suitable reason for changing this
