1533605 - Unexpected CORS blockage for video uploads at streamable.com's mobile site

Status: RESOLVED INCOMPLETE

(Web Compatibility :: Site Reports, defect)

Description

[Thomas Wisniewski [:twisniewski]]

When an attempt to upload a video file on Fennec is made at streamable.com, the POST request to send the file is blocked by CORS with this non-informative message in the console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://transcoder5.streamable.com/upload/0k176. (Reason: CORS request did not succeed).

According to the devtools, this is the OPTIONS request that is made for the XMLHttpRequest in question (with the response headers under the copied-as-Curl command):

curl 'https://transcoder5.streamable.com/upload/0k176' -H 'User-Agent: Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0' -H 'Accept: */*' -H 'Accept-Language: en-CA,en-US;q=0.7,en;q=0.3' --compressed -H 'Referer: https://streamable.com/' -H 'Content-Type: multipart/form-data; boundary=---------------------------22002917911406419151798698032' -H 'Origin: https://streamable.com' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data ''

POST /upload/0k176 HTTP/1.1
Host: transcoder5.streamable.com
User-Agent: Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0
Accept: */*
Accept-Language: en-CA,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://streamable.com/
Content-Type: multipart/form-data; boundary=---------------------------22002917911406419151798698032
Content-Length: 4361246
Origin: https://streamable.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

And this is the request being made (also via copy-as-Curl) along with the request headers:

curl 'https://transcoder5.streamable.com/upload/0k176' -H 'User-Agent: Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0' -H 'Accept: */*' -H 'Accept-Language: en-CA,en-US;q=0.7,en;q=0.3' --compressed -H 'Referer: https://streamable.com/' -H 'Content-Type: multipart/form-data; boundary=---------------------------22002917911406419151798698032' -H 'Origin: https://streamable.com' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data ''

POST /upload/0k176 HTTP/1.1
Host: transcoder5.streamable.com
User-Agent: Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0
Accept: */*
Accept-Language: en-CA,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://streamable.com/
Content-Type: multipart/form-data; boundary=---------------------------22002917911406419151798698032
Content-Length: 4361246
Origin: https://streamable.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

I'm not at all sure why the request would be being blocked, given that info.

(This was originally reported at https://webcompat.com/issues/19130)

Comment 1

[Daniel Veditz [:dveditz]]

CORB is about the response; do you have those? But a POST is either xhr/fetch or a form (= navigation) and I didn't think CORB applied to either.

Comment 2

[Daniel Veditz [:dveditz]]

Sorry, that's a regular CORS error message, CORSDidNotSucceed. It's only sent in 2(3) cases:
1/2 we fail to get the response status, or the status is a failure (e.g. 404)
3 we can't get an nsIHttpChannelInternal out of it

https://searchfox.org/mozilla-central/search?q=CORSDidNotSucceed&path=

The URL in the message looks perfectly valid HTTP, so is the status a failure code?

Comment 3

[Thomas Wisniewski [:twisniewski]]

The devtools don't show any response or status code for the blocked request, so I can't say for sure.

Is there a way for me to find out more on Fennec? I don't mind compiling a debug build if I can analyze a network log or what-not.

Comment 4

[Daniel Veditz [:dveditz]]

If you can do "Copy as cURL" why can't you just look at the response headers in the same place in devtools?

Comment 5

[Thomas Wisniewski [:twisniewski]]

Presumably because there was no response, as the request was blocked by CORS. All I see is request headers, not response headers.

Comment 6

[Daniel Veditz [:dveditz]]

hm, not likely. CORS blocking is done on the client side, and we have to get the response so the CORS algorithm can make its decisions. One reason for that error string as mentioned in comment 2 is not getting a response, but that's something the server decided and isn't really "blocked by CORS". Just happens to be a CORS error in the sense of lack of success.

Comment 7

[Thomas Wisniewski [:twisniewski]]

Then I wonder if it's CORB, and not CORS? The reason I figured it's CORS is because I see a related console message being logged:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://transcoder10.streamable.com/upload/41aln. (Reason: CORS request did not succeed).

But one way or the other, I'll see if maybe I can find the time to add some console logging to a custom Fennec build, and get some more insight. I just may not get around to it anytime soon, given my workload. Or perhaps bug 1157817 will help shed some light on this if it gets done first.

Comment 8

[Daniel Veditz [:dveditz]]

Moving back to WebCompat since we need more info before determining it's actually a bug in our CORS handling.

Comment 9

[Karl Dubost💡 :karlcow]

putting the right email

Comment 10

[Thomas Wisniewski [:twisniewski]]

Unfortunately, streamable.com has changed their site and this no longer reproduces, so further investigation is impossible.