Re: #73: Alt-Svc Elevation of Privilege

yes, with usual caveat that the delay applies to async bg stuff and not qoe
beyond opportunity cost.. so somewhat less impt.

On Mon, Jun 8, 2015 at 11:59 AM, Ryan Hamilton <rch@google.com> wrote:

> FWIW, In the chromium implementation of Alternate-Protocol (and now
> Alt-Svc) we require the new port to be < 1024 if the original port was <
> 1024.
>
> Would CORS incur a latency penalty in these cases? Would we need to wait
> for a CORS request to come back before we could use Alt-Svc?
>
> On Mon, Jun 8, 2015 at 6:11 AM, Patrick McManus <mcmanus@ducksong.com>
> wrote:
>
>> its not optimal, but I would consider some kind of CORS mechanism (or
>> more likely, CORS :)) here as part of the alt-svc establishment.
>>
>> relatedly I've heard concerns about even cross host with the cert check
>> in environments with broad alternates - and the feeling that this bypasses
>> the spirit of CORS. (though I disagree on that count, I do understand it).
>>
>>
>>
>> On Sun, Jun 7, 2015 at 9:46 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> <https://github.com/httpwg/http-extensions/issues/73>
>>>
>>> This issue asks if allowing a header to advertise an alternative on
>>> another port (but still on the same host) is adequate, since in some shared
>>> hosting environments, users will have the ability to add response headers,
>>> as well as listen on other ports.
>>>
>>> Erik has suggested in the issue that it might be helpful to limit these
>>> to privileged ports — i.e., those lower than 1024. I'm assuming such a
>>> restriction would be in place if the origin port were also privileged.
>>>
>>> What do people think?
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>>
>>
>