Skip to content

Gracefully handle invalid Content-Type header from CSTV broadcasts#616

Open
cadenkriese wants to merge 1 commit intomarkus-wa:masterfrom
cadenkriese:master
Open

Gracefully handle invalid Content-Type header from CSTV broadcasts#616
cadenkriese wants to merge 1 commit intomarkus-wa:masterfrom
cadenkriese:master

Conversation

@cadenkriese
Copy link

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.

@markus-wa
Copy link
Owner

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?

@cadenkriese
Copy link
Author

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?

@markus-wa
Copy link
Owner

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 text/html we can be reasonably sure it's not valid.

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)

@cadenkriese
Copy link
Author

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.

@markus-wa
Copy link
Owner

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 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants