Ian Hickson wrote:
On Tue, 17 Jun 2008, Zhenbin Xu wrote:
I am not sure if I understand your question. responseXML.parseError
has the error information
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was returned.
A
Regards,
Jonas Sicking
?
Look forward to hosting the members here in Redmond.
Looking forward to seeing you there!
Best Regards,
Jonas Sicking
_http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm_
The test is expecting us to return NULL in case open() has not been
called. We throw an exception in IE. I’d pre fer if the spec says
*“*MUST return null OR an exception*”* otherwise I fear sites today will
be broken.
Travis Leithead wrote:
Interesting findings (mostly related to IE):
This test tries to define if the HTML event handlers (onFoo) are linked to the
add/removeEventListener APIs in any way (or to define what the relationship is).
Browsers tested: Opera 9.25, Firefox 3 RC1, IE8 Beta1, Safari
Maciej Stachowiak wrote:
On Jun 6, 2008, at 2:20 PM, Travis Leithead wrote:
While implementing some improvements to getAttribute in IE8, we
actually checked in code that is conformant to what the spec says
about the return value:
Return Value
DOMString
The Attr value as a string, or
Ian Hickson wrote:
Chaals, please see the end of this message.
On Wed, 28 May 2008, Jonas Sicking wrote:
It seems to me that everyone agrees that insertNode() was always
intended to insert a node _into_ the range, and that the collapsed
case was simply lost between the cracks when the DOM
For the record: Where the discussion takes place is of little importance
to me and mozilla. It would make sense to me to do it here, but I'm just
as happy to discuss it elsewhere too. So I don't prefer it one place
or the other.
/ Jonas
Charles McCathieNevile wrote:
On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Hi WebAPI fans!
WebAPI! WebAPI! WebAPI!
(Sorry)
I wanted to implement the ElementTraversal spec for the next release
of firefox (after FF3). However last I heard there was still
Julian Reschke wrote:
Anne van Kesteren wrote:
...
We shouldn't let what webidl says dictate what we do one way or the
other. It's just a spec for the idl language, not a recommendation
for how interfaces should behave.
null/undefined are not really part of the setRequestHeader() method.
Anne van Kesteren wrote:
On Sun, 25 May 2008 20:40:48 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Agreed. We have in the past said that in the cases where it doesn't
seem like the web is depending on a certain behavior one way or the
other do what is most useful. I don't really think
. While I agree that it can be more complex to
implement, I still think that the value vs. cost ratio still is quite good.
Best Regards,
Jonas Sicking
On Mon, 23 Apr 2007, Jonas Sicking wrote:
There's a big difference to that and to what I'm proposing. With what's
in bug 80713 you're still limited to a box that basically doesn't take
part of the outer page at all. For example in the table example in my
original post the headers
Thomas Roessler wrote:
On 2008-05-27 11:00:44 -0700, Jonas Sicking wrote:
What I suggest is that we prohibit the Access-Control-Policy-Path
header from being used on URIs that include the string ..\, in
escaped or unescaped form. One worry with this is if there are
encodings which put
It sounds like a bad idea to me that the default behavior for DOMString
should be that null is converted to null. I can't think of a single
case where that is what you want to do.
Granted, this is partially due to a javascript spec bug, null really
should have serialized to rather than
On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I could not find record of any such objection in the Advisory
Committee mailing list archives, or any record of an official W3C
decision on this point. As Team contact, could you please explain who
made this
I also made it clear that the user agent is not to set any headers
other than those on that list and those permitted to be set if the
author has not set them (as explained under the send() algorithm).
So, why are the headers below on the list?
* Accept-Charset
* Accept-Encoding
I
Julian Reschke wrote:
Jonas Sicking wrote:
These should absolutely not be under control of web content.
The Referer header is used by some web servers for security checks so
allowing this to be settable would work around that. Servers can't
currently rely on the header being there due
Anne van Kesteren wrote:
I changed my mind on several things below.
On Fri, 16 May 2008 13:37:54 +0200, Anne van Kesteren [EMAIL PROTECTED]
wrote:
On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
Anne, can you summarise what needs doing to XHR2 and AC to move them
Julian Reschke wrote:
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari are
conformant here. (null and undefined are simply stringified.)
Not
Chris Wilson wrote:
Indeed, there has been a lot of back and forth on the topics of XDR
and XHR2+AC over the last couple of weeks.
As others have pointed out, it hasn't so much been a back-and-forth as
much as the rest of the group asking Microsoft for detailed information
and waiting for
Sunava Dutta wrote:
Inline...
-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 3:14 PM
To: Sunava Dutta
Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
(public); IE8 Core AJAX SWAT Team
Subject: Re: XHR LC comments
Sunava Dutta wrote:
This message is not attempting to set forth in detail all the
objections we have had; Sunava will deliver that in a concise form.
Can you give us a ballpark ETA on this?
[Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to
be ready and available to
Charles McCathieNevile wrote:
On Tue, 13 May 2008 02:54:58 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Charles McCathieNevile wrote:
On Sun, 11 May 2008 18:48:27 +0200, Jean-Yves Bitterlich
[EMAIL PROTECTED] wrote:
Hello,
I understood that prio 1 item on the july 1st-3rd agenda
var ns = http://www.w3.org/1999/xhtml svg=http://www.w3.org/2000/svg;
.querySelector(p svg|svg, ns);
Let ns be an empty hash map, where the key is the prefix and the value
is the namespace uri.
Tokenise the nsresolver string by splitting on whitespace.
For each token:
If there is an '='
Charles McCathieNevile wrote:
On Sun, 11 May 2008 18:48:27 +0200, Jean-Yves Bitterlich
[EMAIL PROTECTED] wrote:
Hello,
I understood that prio 1 item on the july 1st-3rd agenda is going to
be XHR2 (XDR... input). What other items are (known to be) on the
agenda ? (probably 3 days are
Bjoern Hoehrmann wrote:
* Francois Daoust wrote:
In the context of content transformation that is a problem because such
HTTP messages should be passed untouched by the content transformation
proxies: an XHR call involves that some client code will be run on
receipt of the response, so any
Charles McCathieNevile wrote:
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
Hi folks,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has
John Resig wrote:
Hello Everyone -
I just wanted to quickly pull together some of my thoughts concerning
querySelectorAll. I've been asked by a number of people to provide my feedback
here. Please forgive me if I've missed some previous discussions on the subject
matter.
There's three
The added bonus of the current matching is that it does allow for the
selector to leak should you want that for whatever reason.
This isn't really important since this result can already be achieved in another manner,
using .compareDocumentPosition() or .contains() (in IE). However, leaving
John Resig wrote:
But that would mean that .querySelectorAll(:root div) would never
match anything since :root (or :scope) could only match the element
itself, which of course isn't a descendant.
I was under the impression that within the context of a DOM element :root would
be equivalent
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
The issue isn't what we define :scope to match in general. But rather
that you are saying that only descendants of the context node are
allowed to match the individual parts of the selector.
It seems the issue rather is using a pseudo-class
João Eiras wrote:
Unless the page raises another dialog of course
For that there are popup blockers.
The user must click something for another popup to open.
2008/4/29, Bjoern Hoehrmann [EMAIL PROTECTED]:
* João Eiras wrote:
The user can easily and quickly close the dialog and then the
Bjoern Hoehrmann wrote:
As for the suggestion that all links must match one or the other, that
would disallow e.g. reporting accurate results for all visible links
but omitting any invisble link. I don't think that should be disallowed.
How so? All invisible links would match :link, all
Boris Zbarsky wrote:
Lachlan Hunt wrote:
I'm considering adjusting the spec to allow just two options, and
making IE8's behaviour non-conforming.
Either:
1. Match unvisited and visted links normally with :link and :visited,
respecitively.
2. Match all links with :link, and no links with
Hallvord R. M. Steen wrote:
On Wed, 09 Apr 2008 23:50:59 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I've been specifically requested to add such support into IE by
various customers. Most of their use-cases involve script that is
trying to 'clean-up' event handlers for which they
Bjoern Hoehrmann wrote:
* Hallvord R. M. Steen wrote:
What I've understood: it's proposed that if the custom lookupNamespaceURI
function moves nodes between documents, the implementation trying to use
the NSResolver (may|must) throw an error. I don't see why we can't specify
that unless
Doug Schepers wrote:
Hi, Jonas-
Jonas Sicking wrote (on 4/14/08 5:58 PM):
Like Boris points out, there is no need to expose debugging APIs to
web pages. Browsers can expose those thorough internal APIs to their
tools.
Actually, I've seen Web apps that allow creation and debugging
Boris Zbarsky wrote:
Jonas Sicking wrote:
1. Parse selector
2. Walk the DOM and create result using parsed selector.
That seems like the obvious approach.
This way it is ok if the NSResolver mutates the DOM in any fashion.
The result returned from the function will simply be based on what
Jonas Sicking wrote:
Boris Zbarsky wrote:
Jonas Sicking wrote:
1. Parse selector
2. Walk the DOM and create result using parsed selector.
That seems like the obvious approach.
This way it is ok if the NSResolver mutates the DOM in any fashion.
The result returned from the function
Jon Ferraiolo wrote:
Thomas Roessler [EMAIL PROTECTED] wrote on 04/14/2008 08:21:50 AM:
On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote:
On the architecture side, Access Control is just plain wrong,
with the PEP on the client instead of the server, which requires
data to be sent
Boris Zbarsky wrote:
Jonas Sicking wrote:
So this generally can't happen, except through implementation specific
quirks, no? I.e. a page can't create an NSResolver mutates nodes to
the point where it no longer has access to the page.
Sure it can. Setting document.domain will do the trick
Travis Leithead wrote:
From your link, it appears the only reason this was dropped was because the
folks in discussion at the time thought the only use case for this feature was
Accessibility venders (ATs).
It wasn't just dropped because it wasn't needed (because AT doesn't need
to use DOM
Boris Zbarsky wrote:
Jonas Sicking wrote:
oldAddEL = EventTarget.prototype.addEventListener;
Node.prototype.addEventListener = function(type,
I should note that this wouldn't work in recent Geckos, by the way...
I think it might actually, since addEventListener isn't on the nodes
Anne van Kesteren wrote:
Currently XMLHttpRequest Level 2 has restrictions on getting response
headers when doing a cross-site request. I have a feeling these may be
an artifact of the slightly older model.
getAllResponseHeaders() returns the empty string currently.
Jean-Yves Bitterlich wrote:
A few alternatives were proposed here, referred below as
(i) 'attribute NodeList childElements',
(ii) 'Node item(index)' and
(iii) xpath .querySelector.
I personally like (iii) because it is powerful (or is it just queries
that are powerful?), however it
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
I'm not following this argument at all. Neither would content that uses
.globalStorage, .forms, .querySelector or anything else that's not in
the SVG Tiny spec.
We're trying to make a new API here, of course content that uses that
API isn't
If we're not 100% compatible with SVG, why would they oppose an
improvement like the suggested one?
Content that uses childElements[...] would not function correctly
in SVG Tiny 1.2 implementations for no particularily good reason.
I'm not following this argument at all. Neither would
Julien Chaffraix wrote:
Hi everyone,
We are in the process of implementing XHR onprogress attribute on
WebKit and arises a compatibility issue with the Firefox
implementation.
Currently the XHR2 draft specifies that we use the ProgressEvent
interface for onprogress events whereas Firefox uses
Daniel Glazman wrote:
I'm actually not sure. How often do authors want to get the third
child without knowing anything more about it than that it's an
element? Iterating through the kids (by means of ET or '.childNodes')
gives you much more context information (what type of element it is,
Henri Sivonen wrote:
On Apr 2, 2008, at 12:44, Jonas Sicking wrote:
And to what end? To use indexing instead of list-style iteration.
Exactly. Something that I would imagine is quite commonly done. Note
that we're not just talking iterating over a full DOM tree, we're also
talking about
Anne van Kesteren wrote:
On Wed, 02 Apr 2008 08:54:17 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
This is definitely a good question, one that I'd like to see addressed
too.
I think that if the spec remains as is Firefox would likely fire
events that implements both the ProgressEvent
Daniel Glazman wrote:
Jonas Sicking wrote:
Bjoern Hoehrmann wrote:
We could also standardize the popular .getChildrenByTagName() method,
that would give the similar
myFooElement.getChildrenByTagName(*)[3]
This seems like an excellent idea. To do in addition to the
ElementTraversal spec
Bjoern Hoehrmann wrote:
* Daniel Glazman wrote:
1. congrats for this spec, I love it ; I can't count how many times in
page or chrome script I am filtering out nodes that are not element
nodes.
2. the ElementTraversal interface has a |childElementCount| attribute
but misses access to
,
Jonas Sicking
Eric Lawrence wrote:
Ian--
Thanks for sharing your opinions. I'd like to take the opportunity to clarify
a few points of confusion.
This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing
Laurens Holst wrote:
Laurens Holst schreef:
Or, if you really do not want to increase the attack surface, you
should always send the content type application/x-www-form-urlencoded,
and only allow request entities constructed through an API. Because
servers only expect x-www-form-urlencoded
Lachlan Hunt wrote:
Anne van Kesteren wrote:
On Fri, 14 Mar 2008 01:18:27 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Maybe the best solution would be to add a :scope pseudo-element which
is the target of the querySelectorAll call if not called on the
document. That would allow
Jonas Sicking wrote:
How do you define the Intranet, Internet, Restricted etc zones?
Without correct definitions for these zones it seems possible to attack
intranet servers by sending unsafe (such as POST or DELETE) requests to
intranet servers from internet pages.
I'd also recommend sending
Can you describe what you mean by persistent allow design?
/ Jonas
Chris Wilson wrote:
Oops. Obviously, this was not to go to the whole group.
I’ve been asked a lot, over the last week and a half, why we implemented
XDR rather than the current cross-domain XHR proposals. The short
as they relate to this exact subject.
/ Jonas
Jonas Sicking wrote:
So the worry here is a scenario where an attacker tricks a user to go to
evil.com which does an evil POST to webstore.com. And at the same time
the attacker launches a DNS rebind attack on the user for the
webstore.com domain name
Jeff Schiller wrote:
I'm not well-versed on the history behind document.domain and how the
web depends on it being writable. Can someone send me a pointer?
I can understand not letting the embedded object get at the elements
outside of the HTMLObjectElement, but this seems like a weird design
Boris Zbarsky wrote (on 3/13/08 3:11 PM):
It would have
been great if HTMLObjectElement had an accessible params NodeList
readonly attribute :(
Yes, indeed. It's not too late to add that!
Boris, do you mean that it's not too late to add that to Fx3? What
about window.paramList?
It's
How do you define the Intranet, Internet, Restricted etc zones?
Without correct definitions for these zones it seems possible to attack
intranet servers by sending unsafe (such as POST or DELETE) requests to
intranet servers from internet pages.
I'd also recommend sending this to the web
Anne van Kesteren wrote:
On Sat, 08 Mar 2008 00:06:02 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:
Currently getResponseHeader() returns the empty string for invalid
header names. Would people object if I changed that to returning
Kris Zyp wrote:
However, there are web apps in existence (e.g., Gmail)
that set the connection: close header to inform the
user-agent that the HTTP transaction is going to take
a long time. (This is also informative for the
server.) This allows a user-agent to not count this
connection
Morgan L wrote:
Hi, I'm writing about what appears to be an error in
the XHR TR.
In section 2 of http://www.w3.org/TR/XMLHttpRequest/,
it says that setRequestHeader should reject the
connection header.
However, there are web apps in existence (e.g., Gmail)
that set the connection: close
Kris Zyp wrote:
you click on a link, does the link get followed? That is the same
sort of
scenario, isn't it?
At least firefox will abort any existing downloads for the current
page when the user clicks a link. But if you're downloading these
images in another tab you might have this
Collin Jackson wrote:
On Tue, Feb 19, 2008 at 1:10 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
specification we'd have to chose a header name that starts with
Proxy-. There have been many other proposals for new
security-related HTTP headers (e.g. content restrictions) so it would
be
Stewart Brodie wrote:
Kris Zyp [EMAIL PROTECTED] wrote:
We are still faced with the fundamental problem that if a browser that
observes the two connection limit and two long-lived connections are
currently open and the user does something that triggers another request
(such as opening another
Anne van Kesteren wrote:
On Tue, 19 Feb 2008 10:43:14 +0100, Boris Zbarsky [EMAIL PROTECTED] wrote:
The only solution I'm seeing so far to a hanging NSResolver is
terminating that script at some point.
Is that what you're doing for treewalker node filters?
Yes.
I'm not sure why we should
Lachlan Hunt wrote:
Boris Zbarsky wrote:
Anne van Kesteren wrote:
To ensure that naïve implementors don't overlook the potential
issue here. An implementation of NSResolver can be provided by the
script author as the specification explains and the script author
can do all kinds of weird
never have pipelining. That
won't lead to progress. This is our best opportunity to have an inroad
to pipelining, via consenting authors.
Kris
- Original Message - From: Jonas Sicking [EMAIL PROTECTED]
To: Kris Zyp [EMAIL PROTECTED]
Cc: public-webapi@w3.org; Mark Baker [EMAIL PROTECTED]
Sent
Anne van Kesteren wrote:
On Fri, 15 Feb 2008 19:36:21 +0100, Jonas Sicking [EMAIL PROTECTED] wrote:
Lachlan Hunt wrote:
I have added the following text to the spec:
If the user agent also supports some level of CSS, the
implementation
must support the same set of selectors
Hi Sunava,
Thanks for your feedback. I had a couple of additional comments on top
of the ones Anne had.
On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta
[EMAIL PROTECTED] wrote:
o This spec is very different from existing HTML/CSS/DOM spec where
the functionality/API specification is the
Doug Schepers wrote:
Moreover, this is, in fact, what this WG was chartered to do regarding XHR:
This deliverable should begin by documenting the existing
XMLHttpRequest interface.
The question becomes, is IE's implementation to be considered canonical,
or is it up to interpretation vis a
Anne van Kesteren wrote:
Maybe the draft already says something about this, but I couldn't find
it. I think it would be good if there was a way in the IDL to say what
an object stringifies to. The Window object becomes [object Window]
and Location stringifies to its href attribute value.
Maciej Stachowiak wrote:
On Dec 14, 2007, at 4:11 PM, Jonas Sicking wrote:
Julian Reschke wrote:
Jonas Sicking wrote:
Does any currently released browse include the body when doing an
XHR GET request? If a big majority of them currently drop the body,
then it seems like it would help
Anne van Kesteren wrote:
On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
3) The spec as written doesn't state nothing, it appears to clearly
require sending an entity body and does not allow ignoring the body or
throwing an exception regardless of what is
Stewart Brodie wrote:
Jonas Sicking [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
3) The spec as written doesn't state nothing, it appears to clearly
require sending an entity body and does not allow ignoring
Mark Baker wrote:
On 12/14/07, Jonas Sicking [EMAIL PROTECTED] wrote:
Actually, once we're supporting cross site GET requests, I think we
there should definitely mention that the entity body of GET (and
probably HEAD) requests are dropped. Otherwise there is some risk that
there are servers
L. David Baron wrote:
There are a number of interfaces, used as callbacks, like
EventListener [1], NodeFilter [2], and UserDataHandler [3], and
XPathNSEventResolver [4] where an interface has a single method and
is intended to be implemented by the DOM user as a callback. In
ECMAScript
Mike Wilson wrote:
But it turned out in the course of developing the spec that there
were enough individually small differences to make such an excercise
fruitless.
Considering that IE invented XHR (apart from the object
naming), couldn't the first version of the spec just
Boris Zbarsky wrote:
Anne van Kesteren wrote:
I think HTML5 needs to define this as my understanding is that
document.domain is also relevant in deciding whether or not a request
is same-origin.
Actually, I don't think it is. I know IE and Gecko ignore
document.domain for the existing
Anne van Kesteren wrote:
On Mon, 06 Aug 2007 23:39:28 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Given domain A and B I wonder if it's a problem if when a request is
done from A, B can feed information back to A (through the URL;
http://domain-a.org/?data=data) without any sort of access
Anne van Kesteren wrote:
By the way, a request to a same-origin redirect that redirects to a
non same-origin resource should also work I suppose? Or is there some
reason you need to know in advance you're going to make a non
same-origin request?
For GET requests I don't see a reason to not
Alexey Proskuryakov wrote:
On 7/30/07 12:21 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
If XHR2 offers responseBody with a raw byte array of some kind, it will
be required for implementations to keep the raw bytes around anyway.
Yep. Though it still seems weird to me that responseText would
Maciej Stachowiak wrote:
On Jul 27, 2007, at 12:09 PM, Jonas Sicking wrote:
Anne van Kesteren wrote:
I've been looking at overrideMimeType implementations in Gecko and
WebKit and it seems like they differ a bit. In Gecko it has to be
invoked before send(), but in WebKit it would work
Maciej Stachowiak wrote:
On Jul 28, 2007, at 4:04 AM, Anne van Kesteren wrote:
Jonas already mentioned it in another e-mail and this feature was
indeed planned (by me 8-)) for XMLHttpRequest level 2. responseText
already follows text/html rules for encoding detection etc. but for
Anne van Kesteren wrote:
On Fri, 27 Jul 2007 21:09:37 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
It does seem fairly complicated to allow it to be set after the
download is finished though. You do have the stream stored in
.reponse[Text], but at that point all encoding information has
Anne van Kesteren wrote:
Jonas already mentioned it in another e-mail and this feature was indeed
planned (by me 8-)) for XMLHttpRequest level 2. responseText already
follows text/html rules for encoding detection etc. but for parsing we
probably need to state that it needs to run with
Anne van Kesteren wrote:
It seems nicer however to not restrict it to XMLHttpRequest and define
the entire retrieval algorithm in the access-control specification
including how it works for other methods and in face of redirects.
I agree. I don't really want to hold up the [ac] spec though.
Anne van Kesteren wrote:
On Mon, 23 Jul 2007 10:35:27 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
Julian Reschke wrote:
Jonas Sicking wrote:
The XHR spec currently allows users to set the Proxy-Connection
header using setRequestHeader method. I couldn't find a spec for it
other than some discussions here:
...
As far as I can tell, the spec doesn't even mention the header.
Are you
Hi All,
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
cross-site requests should alway have the headers set through
setRequestHeader removed. This
Jonas Sicking wrote:
Hi All,
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
cross-site requests should alway have the headers set through
Julian Reschke wrote:
Jonas Sicking wrote:
Jonas Sicking wrote:
Hi All,
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
cross-site requests should
it feels to me like
redirects and non-GET requests cross site is a rare edge-case and not
something that is particularly important. So we might as well do the
safe thing. I could even see disallowing redirects entirely, even for
the initial GET request.
Best Regards,
Jonas Sicking
Maciej Stachowiak wrote:
On Jul 2, 2007, at 3:50 PM, Charles McCathieNevile wrote:
On Mon, 02 Jul 2007 20:17:40 +0200, Doug Schepers
[EMAIL PROTECTED] wrote:
Hi-
Maciej Stachowiak wrote:
I don't have a strong objection either way, but I think the case
against Lachy's original names
[EMAIL PROTECTED] wrote:
Hi folks,
we need to figure out what is really needed.
A big requirement is security. It must not be possible to connect to an
arbitrary port on the server and send anything, unless the server has
explicitly stated that it allows so using some sort of
1 - 100 of 142 matches
Mail list logo
