Re: [XHR] Redirects
On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher wrote: If instead, we had an API for auditing redirects (perhaps an "onredirect" event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Otherwise, the redirect would be processed normally. The result being that application authors would be guided away from following redirects manually, and hence they would avoid the problems I've described above. This does not work for synchronous requests in a worker. If we are okay with that it seems an acceptable alternative. However, redirects are processed before the object reaches HEADERS_RECEIVED (as otherwise it would reach that several times) so HTTP headers et cetera are not available yet. Given that, and given that you want that information, you would always invoke preventDefault(), defeating the purpose of having an event. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Wed, 01 Sep 2010 00:46:41 +0200, João Eiras wrote: Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available. Something like finalUrl which when readyState is <= 1 it would have the value passed to open() and after, when the value is >= 2 (headers received) it would have the value of the final url. That use case is addressed by implementing redirecting yourself. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On , Anne van Kesteren wrote: On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available. Something like finalUrl which when readyState is <= 1 it would have the value passed to open() and after, when the value is >= 2 (headers received) it would have the value of the final url. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. Following redirects is the default behavior, and user agents abort after N iterations regardless of whether it's XHR or a regular request. The new followRedirects feature is for opting into disabling it. If instead, we had an API for auditing redirects (perhaps an "onredirect" event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Quite an edge case, but setting followRedirects to false and then creating individual XHRs for each 302 response explicitly should work.
Re: [IndexedDB] Constants and interfaces
On 8/31/2010 12:03 PM, Jonas Sicking wrote: So IMHO we should heavily optimize for javascript, while ensuring that other languages are possible. Yes, please. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [XHR] Redirects
On Tue, Aug 31, 2010 at 1:16 PM, Anne van Kesteren wrote: > On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher > wrote: > >> So the idea is that you would have to manually create the redirect request >> using a new XHR if you wanted to manually follow the redirect? >> > > Yeah, or you could reset the existing object using open(). > > > > One risk with that is that it is easy to construct the redirect request >> improperly. There's the classic example of what happens when you issue a >> POST request and it results in a redirect. 303 and 307 had to be invented >> because some browsers implemented 302 incorrectly. >> > > Yeah, though I think that the people that implement redirects manually have > put some thought in the matter. Maybe that is naive, though on the other > hand if people do it wrong it does not matter much either. > > > > Maybe there should be a way to create a new XHR from the existing XHR that >> is already configured to follow the redirect? I'm not sure how to make this >> less awkward... >> > > If this is actually common and people start using this a lot and ask this > question here that would be the point where we should start thinking about > making this less awkward. For now libraries and developers with "lots of > time" have all the hooks they need. > > > > Hmm, that's a pretty good argument. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. The classical example is a server that redirects back to the same URL with a Set-Cookie header, expecting the next request to have a corresponding Cookie header. If the Cookie header is not added, then the redirect is issued again. Most browsers detect this after N iterations, and then give up. Of course, this situation only occurs if the user has disabled cookies in the User Agent. I worry that a case like this will almost never be tested by application developers, and hence, users who like to disable some cookies will be unable to use the internet. (I realize that the internet is mostly broken already if you disable cookies, but there are some variations of cookie blocking that sort of work.) A User Agent could try to implement a heuristic to catch certain flavors of redirect chains, by observing the XHR requests made by an application. But, it seems like it would be fairly difficult to avoid false positives. If instead, we had an API for auditing redirects (perhaps an "onredirect" event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Otherwise, the redirect would be processed normally. The result being that application authors would be guided away from following redirects manually, and hence they would avoid the problems I've described above. -Darin
Re: [XHR] Redirects
On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher wrote: So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? Yeah, or you could reset the existing object using open(). One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Yeah, though I think that the people that implement redirects manually have put some thought in the matter. Maybe that is naive, though on the other hand if people do it wrong it does not matter much either. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... If this is actually common and people start using this a lot and ask this question here that would be the point where we should start thinking about making this less awkward. For now libraries and developers with "lots of time" have all the hooks they need. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 31, 2010 at 4:41 AM, Jeremy Orlow wrote: > On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking wrote: >> >> On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow wrote: >> > On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking wrote: >> >> >> >> On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow >> >> wrote: >> >> > On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking >> >> > wrote: >> >> >> >> >> >> On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow >> >> >> wrote: >> >> >> > On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking >> >> >> > wrote: >> >> >> >> >> >> >> >> On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow >> >> >> >> >> >> >> >> wrote: >> >> >> >> > Last we spoke about constants in IndexedDB, (like >> >> >> >> > IDBKeyRange.LEFT_BOUND) I >> >> >> >> > believe we had decided that all the objects with constants >> >> >> >> > would >> >> >> >> > have >> >> >> >> > an >> >> >> >> > interface object hanging off of window so it's possible to >> >> >> >> > simply >> >> >> >> > say >> >> >> >> > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when >> >> >> >> > someone >> >> >> >> > tries >> >> >> >> > something like the following JS: |IDBCursor.continue()|? Given >> >> >> >> > that >> >> >> >> > we're >> >> >> >> > using an interface object, I'd assume we throw some sort of >> >> >> >> > exception >> >> >> >> > or >> >> >> >> > something? I tried to figure out the answer in the WebIDL spec >> >> >> >> > (I >> >> >> >> > imagine >> >> >> >> > it's somewhere around >> >> >> >> > >> >> >> >> > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) >> >> >> >> > but >> >> >> >> > it's a >> >> >> >> > lot to wade through. Any advice would be great. >> >> >> >> >> >> >> >> I definitely think we should handle this the same way that all >> >> >> >> other >> >> >> >> interfaces does it. I.e. the same way that >> >> >> >> window.Node.appendChild(...) does it. In the Firefox >> >> >> >> implementation >> >> >> >> we >> >> >> >> just fall back to using our generic code for all this stuff, so >> >> >> >> nothing special goes on in the IndexedDB implementation. >> >> >> >> >> >> >> >> And yes, I think WebIDL should be the one defining what should >> >> >> >> happen. >> >> >> >> If it doesn't already someone should file a bug :) >> >> >> > >> >> >> > Ok, I figured out how interface objects are done in WebKit and got >> >> >> > it >> >> >> > implemented. And everything looks like it's working fine except >> >> >> > for >> >> >> > IDBKeyRange. The problem is that IDBKeyRange has 4 factory >> >> >> > methods >> >> >> > attached >> >> >> > to it, but these aren't accessible from the interface object (and >> >> >> > these >> >> >> > factories are the only possible way to get such an object). It >> >> >> > makes >> >> >> > sense >> >> >> > that methods are by default not considered static (i.e. must be >> >> >> > called >> >> >> > on an >> >> >> > instance of the interface). >> >> >> >> >> >> Indeed, the factory methods on IDBKeyRange use a different syntax >> >> >> from >> >> >> every other method in the DOM. This was why we originally proposed a >> >> >> different syntax in our proposal. >> >> >> >> >> >> However I've come to like the current specced syntax quite a bit and >> >> >> would prefer to stick to it actually. It makes for a lot nicer >> >> >> javascript. We might want to change left/right bound to lower/upper >> >> >> bound, but other than that I'd prefer to stick to the current >> >> >> syntax. >> >> >> It does take some trickery to implement in gecko, but not enough to >> >> >> toss it out IMHO. >> >> > >> >> > This isn't just an issue of implementation "trickery". What's >> >> > specced >> >> > doesn't work. Leaving it as is is not an option. >> >> >> >> Agreed. >> >> >> >> > We either need to figure out the right language to describe what we >> >> > intended >> >> > or we need to change it. As I mentioned, I tried to figure out what >> >> > was >> >> > needed spec wise, but couldn't. As far as I can tell, there isn't >> >> > anything >> >> > else out there trying to do this either, so it's very possible this >> >> > behavior >> >> > would require a change to the WebIDL spec. (And blocking on that >> >> > is probably not a good idea given that it's been stagnant for so long >> >> > and >> >> > has quite a backlog of required changes at this point.) >> >> > Can you (or anyone else) think of a way to spec it? >> >> >> >> I think the way to do it is as follows: >> >> >> >> * Remove the factory methods from the IDBKeyRange interface. The >> >> factory methods shouldn't be showing up on individual instances >> >> anyway. >> >> * Add prose below the interface description that states that in > > I think I'd only support this if it was just a stop-gap measure until WebIDL > could add proper support. Is there any way to bring this up with those > folks and get their feelings on the subject so whatever we do > is consistent with the future directions of that spec? I can't say that I care much. Adding it to
Re: [XHR] Redirects
On Fri, Aug 27, 2010 at 5:50 AM, Anne van Kesteren wrote: > On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras > wrote: > >> Between the boolean and an integer, the integer is more useful, although >> seeing long redirection chains is somewhat rare and overkill. >> > > I went for a boolean followRedirects attribute as that gives sufficient > low-level control that people can implement whatever behavior they want on > top of that. (Including every use case mentioned in this thread.) This is an > XMLHttpRequest Level 2 feature now: > > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ > > > So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... -Darin > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Blob/File naming
On Monday, August 30, 2010 1:09 PM, Jonas Sicking wrote: > On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan > wrote: > > *sigh. Naming continues to be hard. Not everyone's thrilled with the > > proliferation of Blob in the API [1] including other major implementors > > (my co-editor included ;-)) but I changed it mainly due to Darin/Jian/other > > objections. I suppose you folks are pretty adamant on the Blob* name? > > I feel pretty strongly that we should name this back to FileReader, > for several reasons: > > 1. Most people that I talk to dislike the name Blob, much less having > it spread to things like BlobReader. > 2. My understanding is that the writer counterpart is going to be > called FileWriter (is this correct?) > 3. While it's certainly possible to read Blobs with this, it seems to > me like the far most common case will be to read a "real" file, or > part of a file (i.e. the result from myfile.slice()). > 4. There is one shipping implementation of FileReader It's easy to bike shed on naming and I don't really want to get into that. I'd prefer we just settled on something and stick to it. However I will offer some observations from the conversations we've been having on this topic. I like the abstraction of Blob away from File with File being a concrete implementation of the Blob interface. I suspect going back to just File adds a bunch of unnecessary things to the cases where the data isn't file backed. It seems there are a proliferation of specs that reference the Blob concept. In fact the confusion in my conversations with people over the name has been about a Blob here being more like a Stream than what they traditionally think of as a BLOB (with a url property for example). We think using Blobs with XHR and IndexedDB, say, will become at least as common as their use for reading files from the file system. Cheers, Adrian.
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren wrote: > On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher > wrote: > >> Another idea (possibly a crazy one) would be to eliminate Blob, and just >> use File for everything. We could rename BlobBuilder to FileBuilder and >> have it return a File instead of a Blob. Same goes for Blob.slice(). Of >> course, >> the File would not necessarily correspond to a real physical file on disk >> for performance reasons. >> > > Not having Blob at all works for me! > > > I gave this some more thought. Here's some issues I came up with: 1) BlobBuilder -> FileBuilder This renaming seems to suggest the creation of a file, which is not the intent at all. 2) XHR.{asBlob,responseBlob} -> XHR.{asFile,responseFile} This renaming seems to suggest the creation of a file, which is not necessary for small responses. 3) Combine Blob and File into a single File interface This merging has the unfortunate side-effect of introducing a "name" property for the result of a File.slice() operation. It also means that the result of FileBuilder and XHR.responseFile would have a name. Considering the above, it seems like there is a place for Blob (or something like it). I can see Jonas' points about BlobReader vs. FileReader, and so I'm happy to backpedal and go with FileReader, FileException, and FileError, keeping Blob for cases where we don't promise a file. -Darin
Re: [IndexedDB] Constants and interfaces
On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking wrote: > On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow wrote: > > On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking wrote: > >> > >> On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow > wrote: > >> > On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking > wrote: > >> >> > >> >> On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow > >> >> wrote: > >> >> > On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking > >> >> > wrote: > >> >> >> > >> >> >> On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow < > jor...@chromium.org> > >> >> >> wrote: > >> >> >> > Last we spoke about constants in IndexedDB, (like > >> >> >> > IDBKeyRange.LEFT_BOUND) I > >> >> >> > believe we had decided that all the objects with constants would > >> >> >> > have > >> >> >> > an > >> >> >> > interface object hanging off of window so it's possible to > simply > >> >> >> > say > >> >> >> > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when > >> >> >> > someone > >> >> >> > tries > >> >> >> > something like the following JS: |IDBCursor.continue()|? Given > >> >> >> > that > >> >> >> > we're > >> >> >> > using an interface object, I'd assume we throw some sort of > >> >> >> > exception > >> >> >> > or > >> >> >> > something? I tried to figure out the answer in the WebIDL spec > (I > >> >> >> > imagine > >> >> >> > it's somewhere around > >> >> >> > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object > ) > >> >> >> > but > >> >> >> > it's a > >> >> >> > lot to wade through. Any advice would be great. > >> >> >> > >> >> >> I definitely think we should handle this the same way that all > other > >> >> >> interfaces does it. I.e. the same way that > >> >> >> window.Node.appendChild(...) does it. In the Firefox > implementation > >> >> >> we > >> >> >> just fall back to using our generic code for all this stuff, so > >> >> >> nothing special goes on in the IndexedDB implementation. > >> >> >> > >> >> >> And yes, I think WebIDL should be the one defining what should > >> >> >> happen. > >> >> >> If it doesn't already someone should file a bug :) > >> >> > > >> >> > Ok, I figured out how interface objects are done in WebKit and got > it > >> >> > implemented. And everything looks like it's working fine except > for > >> >> > IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods > >> >> > attached > >> >> > to it, but these aren't accessible from the interface object (and > >> >> > these > >> >> > factories are the only possible way to get such an object). It > makes > >> >> > sense > >> >> > that methods are by default not considered static (i.e. must be > >> >> > called > >> >> > on an > >> >> > instance of the interface). > >> >> > >> >> Indeed, the factory methods on IDBKeyRange use a different syntax > from > >> >> every other method in the DOM. This was why we originally proposed a > >> >> different syntax in our proposal. > >> >> > >> >> However I've come to like the current specced syntax quite a bit and > >> >> would prefer to stick to it actually. It makes for a lot nicer > >> >> javascript. We might want to change left/right bound to lower/upper > >> >> bound, but other than that I'd prefer to stick to the current syntax. > >> >> It does take some trickery to implement in gecko, but not enough to > >> >> toss it out IMHO. > >> > > >> > This isn't just an issue of implementation "trickery". What's specced > >> > doesn't work. Leaving it as is is not an option. > >> > >> Agreed. > >> > >> > We either need to figure out the right language to describe what we > >> > intended > >> > or we need to change it. As I mentioned, I tried to figure out what > was > >> > needed spec wise, but couldn't. As far as I can tell, there isn't > >> > anything > >> > else out there trying to do this either, so it's very possible this > >> > behavior > >> > would require a change to the WebIDL spec. (And blocking on that > >> > is probably not a good idea given that it's been stagnant for so long > >> > and > >> > has quite a backlog of required changes at this point.) > >> > Can you (or anyone else) think of a way to spec it? > >> > >> I think the way to do it is as follows: > >> > >> * Remove the factory methods from the IDBKeyRange interface. The > >> factory methods shouldn't be showing up on individual instances > >> anyway. > >> * Add prose below the interface description that states that in > I think I'd only support this if it was just a stop-gap measure until WebIDL could add proper support. Is there any way to bring this up with those folks and get their feelings on the subject so whatever we do is consistent with the future directions of that spec? > >> javascript, the interface object IDBKeyRange has the following > >> methods: > >> IDBKeyRange only (in any value); > >> IDBKeyRange leftBound (in any bound, in optional boolean open); > >> IDBKeyRange rightBound (in any bound, in optional boolean open); > >> IDBKeyRange bound (in any left, in any right, in optional boolean > >
Seeking agenda items for WebApps' Nov 1-2 f2f meeting
The WebApps WG will meet face-to-face November 1-2 as part of the W3C's 2010 TPAC meeting week [TPAC]. I created a stub agenda item page and seek input to flesh out agenda: http://www.w3.org/2008/webapps/wiki/TPAC2010 [TPAC] includes a link to the Registration page, a detailed schedule of the group meetings, and other useful information. The registration fee is 40€ per day and will increase to 120€ per day after October 22. -Art Barstow [TPAC] http://www.w3.org/2010/11/TPAC/