[compat] original httpbin combines mulitple header values into comma-separated string

[johnroach]

Hi, started using your httpbin thank you for porting this work to Go!

I have been having a problem when using this solution for headers.

I am wondering if you would be OK with simply returning all headers as a string like httpbin instead of setting as list types. It looks like that is the default behavior for httpbin.org

$ curl -H 'foo: bar' -H 'foo: baz' https://httpbin.org/get
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Foo": "bar,baz",        <===========================
    "Host": "httpbin.org",
    "User-Agent": "curl/7.54.0"
  },
  ...
  "url": "https://httpbin.org/get"
}

vs

$ curl -H 'foo: bar' -H 'foo: baz' https://httpbin.mccutchen.awesome.com/get
{
   "url" : "https://httpbin.mccutchen.awesome.com/get",
   "origin" : "100.112.202.128",
   "args" : {},
   "headers" : {
      "Foo" : [ "bar", "baz" ],     <===============================

   }
}

[mccutchen]

The behavior of the original httpbin service used to be that it would return a single string for single-valued headers or a list of strings for multi-valued headers, and I just adopted the latter form for consistency and ease of implementation. I'm not sure when httpbin switched to returning multiple headers as a single, comma-separated string.

For the moment, I'm 👎 on making this change, because the current behavior seems more "correct" to me. It is an unfortunate break in compatibility with upstream httpbin, though.

Would you mind elaborating on the specific problem you're having with this approach? I want to think about this for a bit, if that's okay!

(And sorry for the delayed reply, I was on vacation for a bit!)

[johnroach]

No problem about the late reply. I hope you had an awesome vacation!

The issue is that our developers wrote a couple hundred tests against httpbin and I wanted to switch to using yours. However, this incompatibility breaks said tests. That is all really.

If you feel strongly about this I understand. That being said I really hope I can use your solution.

Have a great day!

[mccutchen]

I've taken a pass at this and #37 from time to time over the last couple of years, but I'm never satisfied with the complexity that it requires.

Ultimately, I don't think this (admittedly large) part of backwards-compatibility is worth pursuing, and prefer the consistency of our existing approach: any key-value pair where each key may correspond to one or more values will always be represented as a JSON array (AKA list, slice, etc) with one or more items.

(I'd consider this specific behavior related to handling duplicate headers a bug in the original httpbin, because it potentially loses information.)