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
<[email protected]> 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.
