[whatwg] unexpected use of the CORS specification

[Maciej Stachowiak]

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.
>>