Gracefully handle invalid Content-Type header from CSTV broadcasts#616
Gracefully handle invalid Content-Type header from CSTV broadcasts#616cadenkriese wants to merge 1 commit intomarkus-wa:masterfrom
Conversation
|
I couldn't find any documentation that this header is required / expected https://developer.valvesoftware.com/wiki/Counter-Strike:_Global_Offensive_Broadcast The example does set it, but does the CS2 client require it? |
|
Hmm, I'm not sure. I also can't check for you since I don't have access to a machine that can run CS2 client for now. Would you prefer a solution that checks that the content of the payload is valid? |
|
Sorry for the slow reply If there is a reliable way to detect it we can do that, but we need to make sure there is no chance we won't be able to parse legit broadcasts. We could add an inverse content-type detection. e.g. if it's At first I thought we could avoid redirects but there is legit cases where we would want to follow a redirect (e.g. if fragments are hosted on a public bucket and the api redirects to the bucket) |
|
No worries. I see how if we check for application/octet-stream, it's possible that misconfigured servers get incorrectly blocked. If we make sure Content-Type is not text/html then oddly configured servers will break if they redirect to a different Content-Type, starting a game of cat and mouse. Shouldn't application/octet-stream is the only semantically correct Content-Type to describe the data? If so I would check for that header to keep it simple for now. If there are some misconfigured servers in the future then maybe revisit trying to infer the Content-Type from the data. |
|
I think let's first see if cs2 accepts non octet-stream content type. If it doesn't we at least know it's safe to do this, otherwise I'll decide once we know 🙂 |
The Starladder Budapest Majors' CSTV feeds redirect all invalid requests to the major's home webpage. Since those redirects end up returning 200, demoinfocs will append the page HTML to the buffer, causing a panic. My solution is to treat responses that don't use Content-Type: application/octet-stream as errors.