fix: compatible extra semicolon on content-type header

[fengmk2]

No description provided.

[fengmk2]

@dougwilson I think compatible it on type-is is better than koa level.

[dougwilson]

Thanks! I'm not sure the spec allows a semicolon like that, I will need tk check.

[dougwilson]

Yea, checking out the latest RFC, even, it doesn't seem like this is allowed: https://httpwg.org/specs/rfc9110.html#parameter

Each parameter starts with a ; and then would consist of a name, = and the value. A single ; at the end like this would represent an incomplete parameter.

Can you elaborate morw on this change? Where does it fit in to the specs? I tried to look but I could be missing.

Thia module is designed to reject anything outside of the specs on purpose.

[fengmk2]

Yes, the standard specification does not contain an extra semicolon inside. This is a feedback from a real application developer, presumably because the http client implementation that calls their service is not sufficiently standardized to cause them to think that this is a problem with the koa application framework.
Instead of fixing it here, I'll see if I can fix it at the koa or eggjs level.

[dougwilson]

Ah, gotcha. I mean, I'm not 1000% against the idea, but the issue I always end up with these are just what exactly are the exceptions to the rules? Like in this case it accepts foo/bar;a=b;; but then should foo/bar;;a=b be ok too?

The question ends up being what exactly are the exceptions to the rules and how far to go until it turns around and becomes some kind of security vulnerability where multiple systems (like firewalls and proxies) and involved where they are interpreting the same request differently?

[fengmk2]

I think we just need to fix the values that end with semicolon.
foo/bar;;a=b we should not to fixed it.

[dougwilson]

Ok, I see. What is this behavior from? Are we trying to match the behavior of a different web server or just a client? If we are to do this, I would like to know what it is to document and also match how it is doing this so we know we are making it compatible on purpose.

[dougwilson]

Also we'll probably want to have this as a opt-in behavor for non-standards parsing. That usually appeases the sec bug reporters. This is also what node.js has done for it's http parser (they call it insecureHTTPParser but we can just label it as like strict or quirks or something).

[dougwilson]

And, really, in this non-strict/quirks mode, it could just chop the string at the first semi instead of doing the work to validate the media type string is valid or not. That would probably be the most flexible and match what a lot of impls who don't validate the media type are doing (and it would work for this case here too).