CODEWITHSUNDEEP
asp.net-corehttp.syshttp-accept-encodingnetcoreapp3.0
jimnkey
jimnkey

Reputation: 432

Why does http.sys (before IIS) return badrequest when requests have certain acceptable accept-encoding header values?

Given a web app (netcoreapp3.0 hosted in IIS) -- any requests with certain values for Accept-Encoding header never gets to the application. http.sys parses and spits out a 400 - BadRequest.

i.e., Accept-Encoding: application/gzip,gzip

The issue seems to be the '/' character.

We are not in control of the client(s) and would like to not ask to have them conform/change their client's requests. Their requests work with other (non IIS) servers.

Unless I'm reading the spec incorrectly -- I believe the above value is valid for the header. Thought about asking or reporting a bug in github - dotnet/aspnetcore - but not sure if it's a bug.

Thanks for any advice.

Would like to avoid a Kestrel w/ apache | nginx reverse proxy.

Upvotes: 1

Views: 645

Answers (1)

Brando Zhang
Brando Zhang

Reputation: 28267

As far as I know, the accept and accept-Encoding is not the same header. So you read the wrong article.

The right RFC article is :https://www.rfc-editor.org/rfc/rfc7231#section-5.3.4

  The "Accept-Encoding" header field can be used by user agents to
   indicate what response content-codings (Section 3.1.2.1) are
   acceptable in the response.  An "identity" token is used as a synonym
   for "no encoding" in order to communicate when no encoding is
   preferred.

     Accept-Encoding  = #( codings [ weight ] )
     codings          = content-coding / "identity" / "*"

So it doesn't support the "/". There is no way to modify the setting to allow IIS access the wrong header.

Upvotes: 0

Related Questions