Tracking compatibility with original httpbin

[mccutchen]

Let's use this as a place to track compatibility with original httpbin:

Should fix

(See sub-issues for compatibility problems that should be fixed!)

Fixed

• Improve compatibility with httpbin for requests with bodies #89
• Original httpbin returns binary request bodies as base64-encoded data: URIs #90
• feat: add method property to responses #123
• fix: don't update Data when body is empty #125
• /status endpoint should support a weighted choice from multiple codes #145
• Enable all Methods on basic-auth #163
• compat: rename authorized to authenticated in auth responses #231
• compat: fix /cookies response #235

Won't fix

• [compat] original httpbin combines mulitple header values into comma-separated string #15
• [compat] original httpbin returns either lists or scalars depending on input data #37
• Expect: 100-continue with empty request body

[sonbui00]

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"
  ]
}

[mccutchen]

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.

[bleggett]

it should be noted that httpbin returns the following body for HTTP code 418

        -=[ teapot ]=-

           _...._
         .'  _ _ `.
        | ."` ^ `". _,
        \_;`"---"`|//
          |       ;/
          \_     _/
            `"""`

and this implementation does not.

As per https://www.rfc-editor.org/rfc/rfc2324#section-2.3.2 this is strictly speaking in compliance with the RFC (due to the use of MAY versus MUST), but it is a difference in behavior and as such I must point it out.

[mccutchen]

@bleggett please report that as a separate issue (or skip the separate issue and open a pull request to fix it).