Subject: [Wish] Note on cross-origin WISH from browser

From: Cameron Elliott <[email-masked]>
Date: Wed, 14 Jul 2021 13:40:29 -0700

I discovered something recently about WISH from the browser.
(sorry if this has been covered)

Cross-origin (differing domain,scheme or port) WISH POST requests (from the
browser) will be blocked,
which is expected for cross-origin requests.

But, what if we want to do cross-origin WISH to permit publishing to
different ingress points?
(from the browser)

Cross-origin WISH should be doable by using one of the CORS enablement
methods:

There are two main ways of CORS being permitted:
1. With flags to the fetch() method at the browser. ('cors' or 'no-cors')
<https://developer.mozilla.org/en-US/docs/Web/API/Request/mode#value>
2. By the server responding to a a CORS preflight request
<https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests>,
which is an HTTP OPTIONS request involving headers exchange.

Method #1 is NOT available under WISH because WISH doesn't conform to 'simple
requests'
<https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests> under
CORS.
Method #1 would be available under WISH if WISH used or allowed
'plain/text' for the Content-Type header.

Method #2 does allow browser-based cross-origin WISH requests when properly
implemented at the server,
but I would say method #2 is rather unknown (it was to me anyway). I
implemented this, and it's not hard,
but it is not trivial either, compared to getting traditional POST handling
going.

*Does anyone else think it's worth discussing the loss of WISH browser-side
cross-origin request enablement?*

I personally can envision use-cases for WISH where the browser could send
media using WISH
to various different cloud ingress points, where cross-origin requests are
needed.
This won't be possible unless all those cloud ingres points implement
correctly the HTTP OPTIONS method
for handling  a CORS preflight request
<https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests>,
AND the proxies and load balancers properly in front of the ingress
server properly, cleanly pass the HTTP OPTIONS request and response between
client/server,
*unless we decide to make tweaks that enable browser-side CORS enablement.*

Cameron / Seattle

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 15 Jul 2021 19:45:13 +0200

Hi Cameron,

Indeed my intention is that WISH/WHIP works with CORS, and that the HTTP
OPTIONS have to be implemented on the server side in order to allow it.

I thought it was common http-knowledge and there was no need to have it
covered in the spec. I will add it to the slides for the next meeting to
discuss if we should explicitly mention it on the spec or not. Does that
make sense?

Best regards
Sergio

El jue, 15 jul 2021 a las 19:29, Cameron Elliott (<[email-masked]>)
escribió:

> Cross-origin (differing domain,scheme or port) WISH POST requests (from
> the browser) will be blocked,
> Method #2 does allow browser-based cross-origin WISH requests when
> properly implemented at the server,
> but it is not trivial either, compared to getting traditional POST
> handling going.
>
> *Does anyone else think it's worth discussing the loss of WISH
> browser-side cross-origin request enablement?*
>
> server properly, cleanly pass the HTTP OPTIONS request and response
> between client/server,
> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Jul 2021 16:17:19 -0500

For what it's worth, the use of CORS on the web via OPTIONS preflight is 
very common in my experience. I've yet to see a large-scale webapp that 
doesn't make use of it; and I had take for granted that this was the 
approach that WHIP would leverage.

It's probably worth some treatment in the draft, though, for avoidance 
of doubt.

/a

On 7/15/21 12:45, Sergio Garcia Murillo wrote:
> Hi Cameron,
>
> Indeed my intention is that WISH/WHIP works with CORS, and that the 
> HTTP OPTIONS have to be implemented on the server side in order to 
> allow it.
>
> I thought it was common http-knowledge and there was no need to have 
> it covered in the spec. I will add it to the slides for the next 
> meeting to discuss if we should explicitly mention it on the spec or 
> not. Does that make sense?
>
> Best regards
> Sergio
>
> El jue, 15 jul 2021 a las 19:29, Cameron Elliott (<[email-masked] 
> <mailto:[email-masked]>>) escribió:
>
>     Cross-origin (differing domain,scheme or port) WISH POST requests
>     (from the browser) will be blocked,
>     But, what if we want to do cross-origin WISH to permit publishing
>     to different ingress points?
>     (from the browser)
>
>     Cross-origin WISH should be doable by using one of the CORS
>     enablement methods:
>
>     Method #1 is NOT available under WISH because WISH doesn't conform
>     to 'simple requests'
>     but I would say method #2 is rather unknown (it was to me anyway).
>     I implemented this, and it's not hard,
>     I personally can envision use-cases for WISH where the browser
>     could send media using WISH
>     to various different cloud ingress points, where cross-origin
>     requests are needed.
>     This won't be possible unless all those cloud ingres points
>     implement correctly the HTTP OPTIONS method
>     server properly, cleanly pass the HTTP OPTIONS request and
>     response between client/server,
>     /unless we decide to make tweaks that enable browser-side CORS
>     enablement./
>
>
>     Cameron / Seattle
>
>     -- 
>     Wish mailing list
>     [email-masked] <mailto:[email-masked]>