DOM based API
On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu [EMAIL PROTECTED] wrote: Hello, I am interested in working on a specification of a DOM API that allows Web pages to access the user's geolocation information (e.g. latitude and longitude). I'm very glad to see somebody mention using the DOM API for this kind of information, right off the bat. I'm a big believer in reuse, and feel that this API is an obvious candidate for reusing the DOM, i.e. providing a Location Javascript object that's also a DOM Document. I note that you're at Google though, and that the Gears API doesn't reuse the DOM; http://code.google.com/p/google-gears/wiki/GeolocationAPI So I'm wondering if I've misunderstood you, or if Google has had a change of heart, or if you're perhaps not on the Gears team? Cheers, Mark.
Re: Extra Connection Support Proposal
FYI, you might be interested in this recent discussion in the HTTP WG, which could make this proposal unnecessary; http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0423.html Mark.
Re: multipart, server-sent events, and
Hi Maciej, On 2/18/08, Maciej Stachowiak [EMAIL PROTECTED] wrote: Last time I looked into this, there were some proxies and some origin server configurations (in particular certain Apache modules, perhaps now obsolete) that broke with pipelining. Can you define broke? I've done a search on Apache and Squid pipelining bugs, and didn't find any open ones. Since it is not possible to find out from the server if pipelining is correctly supported, and since it is not generally possible to tell from the response that it has failed, enabling it by default in the browser http stack was not a safe thing to do. Since the breakage is caused in at least some cases by proxies, it is not in general safe to let XHR users opt in since they may control the origin server but generally would not control whatever proxies are between the server and the user. Pipelining is a great potential performance improvement and it's sad that it can't safely be used on the public Internet right now, so I hope we someday find a way out of the impasse. Well, I'd like to see some hard evidence of this before we write it off. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: multipart, server-sent events, and
Alex, On 2/11/08, Alex Russell [EMAIL PROTECTED] wrote: Howdy all: So after some brief discussions with Anne and Hixie, I want to start a discussion about some of the open issues I see not being addressed regarding server-sent data. This was agreed as the correct forum for the discussion. I see several major issues that need resolution: * what will become the (defacto) standard for multiple events over a single connection? * what will be done to prevent the current 2-connection limit from locking browsers? First, as background, there are at least 2 partially-implemented solutions available in browsers today. Opera has included an implementation of the WHATWG's sever-sent events, which rely on a simple wire format. The other native option for receiving multiple messages without closing/re-opening a connection is the multipart/x-mixed-replace system (currently implemented in a semi-workable fashion by Mozilla). I always wondered why plain old multipart/mixed was never used, with Content-Location headers per part. It would even be more general, permitting multiple streams to be muxed over a single connection. Is there just the one implementation of x-mixed-replace? Given that WHAT-WG seems to be leaning away from server-sent events, and noting that neither approach solve the 2-connection limit problem, I'd like to propose the following for consideration: * that multipart/x-mixed-replace for textual content over XHR be fully specified by this working group * that a new XHR readyState be defined for message end as distinct from HTTP connection close or that some other property or event be made available to test for overall connection state Presumably you're referring to an event per part here, so perhaps part end instead of message end? * that a new settable property be added to XHR objects which controls how the HTTP connection created by the object is accounted for against the HTTP 1.1 specified 2-connection limit. Not sure what you mean by accounted for, but HTTP doesn't specify that limit, it's just defacto via implementation. Today, if multiple tabs open Comet connections to the same originating server, no document in the browser may request any resources from that server, effectively locking the domain from further use until one of the Comet connections is closed. Instead of a blanket bump to the connection limit (which has un-desireable consequences for existing servers) Indeed. Yes, let's not do that. , it may be preferable for servers to be able to provide a header which effectively discounts the connection or a client-side toggle which allocates the connection against a different, per-document limit of connections (up to some high global maximum). What would the toggle do? It seems to me that browsers just need the per-document connection limit you mention. I reckon I'm asking for a bit more detail on your proposal, but it does seem headed in the right direction. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: [XHR] send doesn’t explain what to do when method is GET
On 12/7/07, Boris Zbarsky [EMAIL PROTECTED] wrote: Bjoern Hoehrmann wrote: Is it conforming for a UA to drop the body for GET requests? Not as far as I can tell. I'd like to request that this be changed, then. Otherwise you're effectively requiring UAs to rewrite their HTTP layers to support entity-bodies with GET requests (or switch to using different HTTP libraries, etc). If you're using a library which doesn't support entity bodies on GET, then that can only be because it special cases GET when it shouldn't. Sounds like a bug to me. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: XHR data: and javascript: requests (was: Re: XHR: definition of same-origin)
On 10/2/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Tue, 25 Sep 2007 14:52:17 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: It would be nice to get some implementation feedback on what to do about data:, javascript: etc. Determining the origin of data:, javascript: URIs when they are responsible for making the request is defined by HTML5, but it's not really clear to me what should happen when somebody does: 1. client.open(data:...) 2. client.open(javascript:...) should that always work or always throw? Testing shows that browsers throw (Firefox, Internet Explorer, Opera), except that Opera allows access to data:. The simplest thing to do would be to disallow everything that does not have any of the scheme, ihost or port components, but I'm open to other suggestions. Opera's behaviour sounds sensible. I'd throw on javascript: because the embedded script could do arbitrary things, whereas the calling script presumably expects open() to have predictable side effects. I suppose that a data:text/javascript,... URI should also throw if it the agent would otherwise execute the embedded script. But I see no harm in permitting any other non-executable-content data: URIs to be open()ed. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: XMLHttpRequest: Why list HTTP method names
On 10/16/06, Robin Berjon [EMAIL PROTECTED] wrote: On Oct 14, 2006, at 15:20, Anne van Kesteren wrote: On Fri, 13 Oct 2006 14:18:56 +0200, Robin Berjon [EMAIL PROTECTED] wrote: And you guarantee interoperability how? It's not the job of the XMLHttpRequest specification to guarantee interoperability on HTTP level features, imho. Anyway, as indicated, this is likely to be tested in the testsuite. If you can't guarantee that at least a core set of methods will work, the API is simply useless. I disagree. Common practice with HTTP is what declares what methods are in use at any given time. As an API to HTTP - which provides portability, not interoperability - XHR doesn't need to say anything about that. All it really needs to say about methods in order to remain a good HTTP API is SHOULD support other methods, which we've said. Anyhow, I think this issue is closed now, right? Mark.
Re: XMLHttpRequest: Why list HTTP method names
Maciej, On 10/17/06, Maciej Stachowiak [EMAIL PROTECTED] wrote: A minimal set should definitely be stated, otherwise the API spec doesn't guarantee enough to do anything useful and code will inevitably depend on implementation conventions. An implementation that did not support, say, GET or POST but only did HEAD would be useless. Of course. But you don't need a spec to tell you that. Mark.
Comments on File Upload
Commenting on; http://dev.w3.org/cvsweb/~checkout~/2006/webapi/FileUpload/publish/FileUpload.html?rev=1.2content-type=text/html;%20charset=iso-8859-1 Editorial; - sec 1, This interface should be This specification - sec 3, I'd suggest s/apparition/display/ Substantive; - sec 3, regarding On devices that have no file system, the user-agent MAY still open a dialogue for data acquisition, for instance an interface to a built-in camera, my concern is that the file dialogue should be considered generic, not specific to any form of data, so I don't want to give the impression that the device can choose the data without user involvement. So I'd suggest for instance, a dialog which identifies a built-in camera and a microphone. - sec 4, not that I care that much, but do we really need this interface? Would an array not suffice? It can't do remove, of course, but is that such a big deal? - sec 4, I don't think SHOULD is appropriate there, for selecting multiple files - MAY should be fine. Plus I think it's best specified in sec 3. - sec 5, filesize - do we know the use cases for this? I don't think the definition provided would be useful for much beyond scenarious using some files in a file system. What if a camera had an 8MB buffer, but image sizes could be up to that size? Or similarly, what about an audio stream? And is this meant to be a string? - sec 5, mediatype - do both and null values indicate that the agent doesn't know the media type? And are we expecting this to be just be the foo/bar value, or would parameters also be included? Need some references too. Mark.
Re: Comprehensive List of Implementations for Testing
On 9/21/06, Antoine Quint [EMAIL PROTECTED] wrote: Mobile Opera 8.5+, 9.0+ BitFlash (v?) Ikivo (v?) ACCESS NetFront should also be listed there. Also, to the best of my knowledge, no shipping version of the Opera browser so far has provided native support for SVG. The Blackberry browser could be listed too, v4.1 up (and if you're using a BIS or BES, which nearly everybody would be). Mark.
Re: Comprehensive List of Implementations for Testing
I don't, Antoine., but hopefully Scott does - Scott? -- Mark Baker Manager, Standards Research in Motion Ltd. (M) +1.613.301.5470 - Original Message - From: Antoine Quint [EMAIL PROTECTED] To: Mark Baker [EMAIL PROTECTED] Cc: Doug Schepers [EMAIL PROTECTED]; Web API public public-webapi@w3.org Sent: Thu Sep 21 15:08:51 2006 Subject: Re: Comprehensive List of Implementations for Testing On 21 sept. 2006, at 19:31, Mark Baker wrote: The Blackberry browser could be listed too, v4.1 up (and if you're using a BIS or BES, which nearly everybody would be). Not sure what BIS or BES is, but I was under the impression that Blackberry devices were, for the time being, supporting only a non- standard subset of SVG that did not include support for scripting. Do you have more info on that Mark? Antoine -- Blog — http://the.fuchsia-design.com - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: XMLHttpRequest HTTP methods
SYNTAX_ERR sounds like a good start. Not sure about SECURITY vs. NOT_SUPPORTED though. I've got a (partial) proposal for the bulk of the issue in my draft folder, I'm just tied up with other stuff right now and have no time to finish it up. Mark. On 8/11/06, Anne van Kesteren [EMAIL PROTECTED] wrote: On Fri, 11 Aug 2006 14:15:23 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: I propose that for the open() method we throw a SYNTAX_ERR when the first argument does not match the token production of RFC 2616 and a (not yet defined) SECURITY_ERR when the method is not allowed for security reasons. Depending on whether we go for a blacklist or whitelist we can also have a NOT_SUPPORTED_ERR I suppose. For the user and password and perhaps the uri argument something similar has to be done I guess. This is related to ISSUE-74 fwiw. If you want your thoughts to be recorded please mention the literal string 'ISSUE-74' in any follow-up e-mails. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XmlHttpRequest IDL non normative
+1 On 7/24/06, José Manuel Cantera Fonseca [EMAIL PROTECTED] wrote: If you are not going to use the sintax and semantics of OMG-IDL it could be better not specifying the object in IDL. You could do it directly in EcmaScript. IDL is accurate when you have to deal with multiple programming languages, but this is not the case.
Re: Include Referer-HTTP-header in requests from XMLHttpRequests
On 6/29/06, Mark Nottingham [EMAIL PROTECTED] wrote: See my previous message; the whole point is that Referer is *not* under the control of the author, but instead automatically generated based on the user's context. I understand, but I don't see it as a large burden to ask that authors do this; r.setRequestHeader( Referer, this.location.href ); Mark.
Fwd: Extension methods XMLHttpRequest
Discussion seems to have died down, and it's there for people to look at for themselves, but I wanted to forward this response from Roy Fielding (HTTP URI editor), as there wasn't much push-back on it. -- Forwarded message -- From: Roy T. Fielding [EMAIL PROTECTED] Date: Jun 11, 2006 2:31 PM Subject: Re: Extension methods XMLHttpRequest To: Bjoern Hoehrmann [EMAIL PROTECTED] Cc: Mark Nottingham [EMAIL PROTECTED], HTTP Working Group [EMAIL PROTECTED] On Jun 11, 2006, at 10:09 AM, Bjoern Hoehrmann wrote: You'll have to look at this from the user perspective. A browser that does not allow (for example) TRACE requests is less risky to use than one that does allow it. The question for browser vendors is then Do we want to make a product that's more risky to use than competing products? That is absolutely absurd. How about making a product that obeys the relevant standards? As I've stated numerous times on this list, the only reason there is any concern about TRACE is because one company that specializes in security used it as a marketing promotion to point out a bug in an old version of MSIE. There is no reason for browsers to block TRACE. What browsers need to do is obey the specs. TRACE is not a problem. If the browser sends already-non-secure cookies on a TRACE request, then the response is going to contain those cookies. So don't do that. Don't whitelist methods -- whitelist the information the browser is allowed to send in *any* request. Allow the user to configure the browser differently when new information is needed. CONNECT is a protocol switch. The only real risks for CONNECT are for proxies that are tricked into connecting to the reserved ports of older protocols. For that reason, good systems limit CONNECT requests to the well-known SSL-using ports and do not send things like cookies in the CONNECT request. Again, this should be configurable by the user. All HTTP methods fall into safe/unsafe categories. It is absolutely necessary that the browser distinguish between safe requests (hyperlinks) and unsafe requests (a la buttons). That is a browser GUI issue and, for scripting, requires a user ack prior to sending the unsafe request. By default, all unknown methods should be considered unsafe until the user configures otherwise. There is no need for the *protocols* to define whitelists when the developers can do so on their own, based on their own applications, and according to their own user needs. Roy
ACTION-144 complete
I've inquired on the old HTTP WG mailing list about their views on supporting extension methods; http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/thread.html#msg33 ... which closes ACTION-144 on Dean to get me to do that. Mark.
Re: Extension HTTP methods
On 5/22/06, Mark Baker [EMAIL PROTECTED] wrote: I think that was ACTION-145 on Gorm. Doh, I meant to paste this; http://www.w3.org/2006/webapi/track/actions/145
Re: XMLHttpRequest.abort()
On 5/15/06, Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 15 May 2006 22:50:52 +0200, Mark Baker [EMAIL PROTECTED] wrote: I think we could be more specific about what reset the object means, That's defined in the definition section. In theory it's also linked, but I'm not sure if that works at the moment. And that section doesn't really cut it either, IMO. It doesn't answer my questions about what reset means to the state of the object (cookies, auth credentials, for example). If nobody has a quick answer, I'll record a new issue. Mark.
Re: XMLHttpRequest.abort()
On 5/14/06, Jim Ley [EMAIL PROTECTED] wrote: Ian Hickson [EMAIL PROTECTED] Do we really want to define in that level of detail? No. +1 When invoked, this method MUST cancel any network activity for which the object is responsible and reset the object. That's fine. And more than enough. I think we could be more specific about what reset the object means, unless we want developers to be exposed to the implementation of the object. Some post-conditions would be useful, I think. For example, does abort() clear (session) cookies? HTTP auth credentials? Does any other (indirectly) observable state get changed? Anybody know? If not, I guess some tests are in order ... Mark.
Re: Headers / caches proposal (revised)
Maciej, On 5/3/06, Maciej Stachowiak [EMAIL PROTECTED] wrote: On May 3, 2006, at 5:19 PM, Mark Baker wrote: On 5/2/06, Maciej Stachowiak [EMAIL PROTECTED] wrote: BTW, I don't think only appended to solves it, since one of the anticipated problems is that Close could be added and may break an existing persistent connection. If by break you mean close cleanly, sure. But there's little harm in that in general, since UAs already have to know to start new connections if one fails (and another isn't available from the pool). And I would think that being able to close connections could be useful in some cases. I'm not sure network libraries will all react gracefully to a Connection: close they did not add themselves. I can't think of a reason why they wouldn't; as I say above, they already have to accomodate connections which drop for a multitude of reasons. Alternately, if folks feel strongly about this, we could prevent close from being added to the Connection header. That would end up with disallowing close and also any header field that the XMLHttpRequest client may not set at all, or may only append to (since we would not want to allow clients to force the proxy to remove the UA-set value). Sorry Maciej, I don't understand what you mean there. That would be much more complicated than the restrictions on any other header field, which are either you can't set it at all or you can only add to but not replace the UA value. Is being able to set Connection a sufficiently compelling use case to warrant this additional complexity? Well, it prevents any future hop-by-hop extension headers from being used. Since we can't know what kind of extensions might be defined in the future though, it's impossible to know exactly what it'll cost us today. But it is a fairly broad chunk of HTTP functionality/extensibility to make inaccessible. Note that we did not choose to do this for other headers where some values might be valid and interesting but others might be problematic. Connection does not seem obviously more useful than Accept-Encoding for instance. I think it is, because while we don't expect XHR apps to manage content codings (that layer is hidden from them), the scope of Connection isn't limited low layer functionality. Mark.
Re: Issue: request bodies
On 4/22/06, Mark Nottingham [EMAIL PROTECTED] wrote: I do agree that HTTP isn't very clear on this matter, but I couldn't find any immediately apparent discussion in the WG. Do you have a ref? AFAIK, this is the latest discussion on the topic, which has some links to previous discussions; http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/thread.html#msg24 What do you think a request body on GET will mean? What developers will probably do with it -- especially if forthcoming access control mechanisms have a higher barrier for POST -- makes me shudder. On the XML Protocol WG years ago, I suggested it could be used to carry a SOAP envelope (without a SOAP body), effectively adding the SOAP processing model to GET. I expect other uses to be similar, basically as a means for transferring alternate serializations of header extensions. FWIW, I don't expect folks to use this just because the API allows it. How many would have thought to have tried it in the first place? I haven't looked at the access control stuff yet. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Re: ISSUE-75: Is method case-sensitive?
I agree. I'm not aware of any HTTP extension methods which use a lower case character, so why not make method case-insensitive, but prescribe that it be converted to upper case in the HTTP message? Mark. On 4/18/06, Anne van Kesteren [EMAIL PROTECTED] wrote: On Tue, 11 Apr 2006 23:54:43 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: * Web APIs Issue Tracker wrote: ISSUE-75: Is method case-sensitive? We resolved that yes, the parameter is case-sensitive. This implies that scripts like those in the draft are essentially incorrect since there is no 'get' method yet. I think we should have a very visible warning for this in the draft then. So what testcases were being used? I understand that this is what HTTP says but if implementations are different (for XMLHttpRequest at least) we should have some reasons and arguments for making it case-sensitive. I'd like this issue to be reopened because there's not sufficient information on how the group reached consensus on it. (I read the minutes.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/ -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Re: ISSUE-75: Is method case-sensitive?
On 4/20/06, Robin Berjon [EMAIL PROTECTED] wrote: The real danger here is that the WG will be tempted to use the API to profile other parts of HTTP for convenience, or based on current implementations, as well. Please, don't. Precisely. Anne raised concerns about exiting CR, but if we start profiling HTTP we'll never get out of LC. I can already hear the hordes clamouring when you pry RFC 2616 from the impervious grasp of my cold, dead fingers. I'm as big an HTTP bigot as there is 8-), but really, this is as inconsequential as it comes; 15 years of deployment, and nary a lower or mixed-case method name to be found, never mind commonly used. And it's not like any functionality is being lost. If there's another option that is both backwards compatible and doesn't profile HTTP, that would of course be preferred. I just couldn't see one. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
