Tracking compatibility with original httpbin about go-httpbin HOT 2 OPEN

Good catch, thanks. I think we should include both Content-Length and Content-Type to match original httpbin.

Are you interested in opening an issue for that specific feature and/or opening a pull request to implement it? (An interesting question is what should happen if the request specifies different, incorrect values for those two headers; might be worth seeing how httpbin.org handles those cases.)

But, to be clear, go-httpbin will continue to serialize header values (and form values and any other “zero or more” values inherent to HTTP) as JSON arrays for consistency, where original httpbin serializes them as single scalar values, arrays, or comma-separated strings, depending on the endpoint and incoming request parameters.

from go-httpbin.

I got a different response

Original
 curl https://httpbin.org/response-headers\?access_token\=faketoken\&token_type\=Bearer   
{
  "Content-Length": "128", 
  "Content-Type": "application/json", 
  "access_token": "faketoken", 
  "token_type": "Bearer"
}

go-httpbin
 curl http://httpbin:9100/response-headers\?access_token\=faketoken\&token_type\=Bearer  
{
  "access_token": [
    "faketoken"
  ],
  "token_type": [
    "Bearer"
  ]
}

from go-httpbin.