Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking compatibility with original httpbin #91

Open
9 of 11 tasks
mccutchen opened this issue Nov 10, 2022 · 4 comments
Open
9 of 11 tasks

Tracking compatibility with original httpbin #91

mccutchen opened this issue Nov 10, 2022 · 4 comments
Labels
compat Tracking issues around compatibility with original httpbin implementation

Comments

@mccutchen mccutchen added the compat Tracking issues around compatibility with original httpbin implementation label Nov 10, 2022
mccutchen pushed a commit that referenced this issue Jun 18, 2023
```console
# before: httpbingo lacks the "method" field but httpbin.org has it
$ curl -s https://httpbingo.org/anything | jq .method                                                                                                        9:31PM
null
$ curl -s https://httpbin.org/anything | jq .method
"GET"

# after: httpbingo has the method field!
$ curl -s http://0.0.0.0:8080/anything | jq .method
"GET"
```

This was mentioned in #6, but then not listed in #91

- I took the highly technical testing approach of adding a test for
`Method` anywhere in `handlers_test.go` that mentioned `Args`; do you
desire more tests? fewer tests?
- Anywhere else I should add this field that I didn't already?

For what it's worth, I discovered this when working on upgrading the
testing for our [httpsnippet
library](https://github.com/readmeio/httpsnippet); I wanted to use
`go-httpbin` but our tests expect the method field to be present in the
responses
@sonbui00
Copy link

sonbui00 commented Aug 6, 2023

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
Copy link
Owner Author

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
Copy link

bleggett commented Oct 3, 2024

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
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat Tracking issues around compatibility with original httpbin implementation
Projects
None yet
Development

No branches or pull requests

3 participants