Subject: Alt-svc and CORS

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Oct 2015 07:40:17 +0000

Hi,

Assume the following case:

1.       A browser requests a page, index.html, from origin example.com.

2.       The page contains an image resource from pictures.com

3.       A cross origin request for the image is sent to pictures.com. The Origin header value in the request is "example.com".

4.       pictures.com has set its CORS policies to allow access to the image from origin example.com, so it accepts the request and sends a response with the image. The ACAO header value in the response is "example.com".

5.       The browser receives the image, and renders it on the page.

So far so good.

Then, assume that example.com uses Alt-svc, and provides index.html also from duxample.com. Now, assume the following case:

1.       The browser requests index.html from origin duexample.com (based on whatever logic)

2.       The cross origin request for the image is sent to pictures.com

QUESTION #1: When the request for the image is sent to pictures.com, will it contain an Alt-Used header? Note that picture.com is not an alternative service.

QUESTION #2: When the request for the image is sent to pictures.com, what will the value of the Origin header be?

1)      As Alt-svc is not supposed to change/replace the origin, will the header value be "example.com"?; or

2)      Will the header value be "duxample.com"? If so, does that mean that picture.com will not accept the image request, as the CORS policy only gives access to example.com? Would picture.com need to be aware of each alterative service of example.com, and give access to the image to each of the alternative service? That doesn't sound right.

Regards,

Christer

---

From: Julian Reschke <[email-masked]>
Date: Wed, 7 Oct 2015 10:32:35 +0200

On 2015-10-07 09:40, Christer Holmberg wrote:
> 1.A browser requests a page, index.html, from origin example.com.
>
> 2.The page contains an image resource from pictures.com
>
> 3.A cross origin request for the image is sent to pictures.com. The
> Origin header value in the request is “example.com”.
>
> 4.pictures.com has set its CORS policies to allow access to the image
> from origin example.com, so it accepts the request and sends a response
> with the image. The ACAO header value in the response is “example.com”.
>
> 5.The browser receives the image, and renders it on the page.
>
> So far so good.
>
> Then, assume that example.com uses Alt-svc, and provides index.html also
> from duxample.com. Now, assume the following case:
>
> 1.The browser requests index.html from origin duexample.com (based on
> whatever logic)
>
> 2.The cross origin request for the image is sent to pictures.com
>
> QUESTION #1: When the request for the image is sent to pictures.com,
> will it contain an Alt-Used header? Note that picture.com is not an
> alternative service.

My understanding is that the header field should not be sent. We 
currently say in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-latest.html#rfc.section.5.p.3>:

"When using an alternative service, clients SHOULD include a Alt-Used 
header field in all requests."

Maybe change this to

"When using an alternative service, clients SHOULD include a Alt-Used 
header field in all requests sent to that service."?

> QUESTION #2: When the request for the image is sent to pictures.com,
> what will the value of the Origin header be?
>
> 1)As Alt-svc is not supposed to change/replace the origin, will the
> header value be “example.com”?; or
>
> 2)Will the header value be “duxample.com”? If so, does that mean that
> picture.com will not accept the image request, as the CORS policy only
> gives access to example.com? Would picture.com need to be aware of each
> alterative service of example.com, and give access to the image to each
> of the alternative service? That doesn’t sound right.

Yes, it would be 1).

We currently say in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-latest.html#rfc.section.2.p.4>:

"Alternative services do not replace or change the origin for any given 
resource; in general, they are not visible to the software "above" the 
access mechanism. The alternative service is essentially alternative 
routing information that can also be used to reach the origin in the 
same way that DNS CNAME or SRV records define routing information at the 
name resolution level. Each origin maps to a set of these routes — the 
default route is derived from thr origin itself and the other routes are 
introduced based on alternative-protocol information."

Isn't that sufficient?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Oct 2015 10:35:55 +0200

> 1.       The browser requests index.html from origin duexample.com (based on

Here's your problem.  The browser makes the request to the origin
example.com.  The fact that a server at duxample.com is serving this
request is irrelevant in this context.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 7 Oct 2015 11:00:48 +0200

> request is irrelevant in this context.

Right. That's a better way to explain it :-)

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Oct 2015 09:15:46 +0000

Hi,

> Right. That's a better way to explain it :-)

That's good.

But, would it be good to include some explicit clarification text, saying that the value of the Origin header doesn't change?

Regards,

Christer

---

From: Patrick McManus <[email-masked]>
Date: Wed, 7 Oct 2015 10:33:37 -0400

On Wed, Oct 7, 2015 at 5:15 AM, Christer Holmberg <
[email-masked]> wrote:

>
>
> But, would it be good to include some explicit clarification text, saying
> that the value of the Origin header doesn't change?
>

Julian already cited

resource; ,"

seems satisfactory, right?

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 8 Oct 2015 12:09:56 +0900

> seems satisfactory, right?

Mostly yes. But it might be clearer to write something like
"Alternative services do not replace or change the Origin for any given 
resource"
or
"Alternative services do not replace or change the origin for any given 
resource (including the Origin header)"
or something along these lines.

Regards,   Martin.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Oct 2015 06:37:36 +0000

Hi,

>>> But, would it be good to include some explicit clarification text, 
>>> saying that the value of the Origin header doesn't change?
>>>
>>
>> Julian already cited
>>
>> "Alternative services do not replace or change the origin for any 
>> given resource; ,"
>>
> Mostly yes. But it might be clearer to write something like "Alternative services do not replace or change the Origin for any given resource"
> or
> "Alternative services do not replace or change the origin for any given resource (including the Origin header)"

Something like that is what I had in mind, yes :)

Regards,

Christer