bug: /response-headers can't cope with quotes

[alxndrsn]

Maybe deliberate?

expected

should behave the same as httpbin?

$ curl 'https://httpbin.org/response-headers?x="'
{
  "Content-Length": "82", 
  "Content-Type": "application/json", 
  "x": "\""
}

observed

breaks weirdly:

$ curl 'https://httpbingo.org/response-headers?x="'
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

[mccutchen]

Ooh, interesting report, thanks! There is no code I can think of in go-httpbin itself that would reject these requests, but there are a number of places this might be happening, like:

• In fly.io's routing layer, which must be traversed to reach the public https://httpbingo.org instance
  • Need to test this with a locally-running instance
• In the Go stdlib's HTTP2 implementation
• In the Go stdlib's common HTTP implementation
• etc

Just a heads up:

• I probably won't get around to poking at this more for the next 2-3 weeks
• there's a decent chance this will end up being marked WONTFIX if it's in a layer we don't control.

[mccutchen]

Also note that there seems to be an element of the way curl itself does or does not automatically percent-encode the URL's query parameters involved.

This works — KINDA — if you visit https://httpbingo.org/response-headers?x=%22 in at least Firefox (though the response still differs from original httpbin's):

[mccutchen]

there are a number of places this might be happening, like:

• In fly.io's routing layer, which must be traversed to reach the public https://httpbingo.org instance
  • Need to test this with a locally-running instance

Okay, now I do think this is somewhere in fly.io's HTTP routing layer, because it does kinda work if curl can send the request directly to go-httpbin itself:

# after `make run` in another terminal
$ curl 'http://localhost:8080/response-headers?x="'
{
  "x": [
    """
  ]
}

[mccutchen]

Okay, here's where I ended up:

• This will not be fixed for the publicly available instance of go-httpbin deployed at https://httbingo.org
  • It appears to be rejected at fly.io's routing layer, which is outside my control
  • based on my (limited!) understanding of the various RFCs I suspect that fly.io is actually right to reject the request as being malformed to prevent e.g. potential request smuggling attacks
• This report did highlight a bug added in the fix for GHSA-528q-4pgm-wvg2, which I landed a fix for in fix: /response-headers does not need escaping by default #208

So now, the latest release of go-httpbin does not HTML-escape the x=" parameter — assuming it actually receives the request, as it will when running locally:

$ curl 'http://localhost:8080/response-headers?x="'
{
  "Content-Type": [
    "application/json; charset=utf-8"
  ],
  "x": [
    "\""
  ]
}

Thanks a lot for the report @alxndrsn (and I apologize for the noise as I made debugging notes for myself)!