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

[Adam Roach <[e-mail]>]

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 (<[e-mail] 
> <mailto:[e-mail]>>) escribió:
>
>     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
>
>     -- 
>     Wish mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/wish
>
>