- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 08 Nov 2009 17:35:19 -0800
On Nov 8, 2009, at 7:25 AM, Adam Barth wrote: > I don't see the connection with CORS. The browser is free to request > whatever URLs it wants. The results need not be accessible to > content. Maybe I'm misunderstanding. The proposal at the link was for a method to do URL unshortening as a client-side script in the browser. That would indeed require CORS. A feature built-in to the browser would not. Regards, Maciej > > Adam > > > On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer > <silviapfeiffer1 at gmail.com> wrote: >> Hi, >> >> a friend of mine just wrote an interesting blog post about >> "unshortening twitter URLs", see >> http://benno.id.au/blog/2009/11/08/urlunshortener . >> >> In it he proposes that url shorteners should be treated specially in >> browsers such that when you mouse over a shortened url, the browse >> knows to interpret them (i.e. follow the redirection) and shows you >> the long URL as a hint. I would support such an approach, since I >> have >> been annoyed more than once that shortened URLs don't tell me >> anything >> about the target. As part of this would be a requirement for URL >> shorteners to support CORS http://www.w3.org/TR/cors/, which browsers >> can then use to follow the redirection. >> >> Further, Benno suggests extending http://www.w3.org/TR/ >> XMLHttpRequest/ >> with a property to disable following redirects automatically so as to >> be able to expose the redirection. >> >> I am not aware if somebody else has suggested these use cases for >> CORS >> and XMLHttpRequest before (this may not even be the right fora for >> it), but since these are so closely linked to what we do in HTML5, I >> thought it would be good to point it out. I would think that at >> minimum Anne knows what to do with it, since he is editor on both. >> >> Regards, >> Silvia. >>
Received on Sunday, 8 November 2009 17:35:19 UTC