-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add support for empty response bodies #54
Conversation
def content | ||
if response_body.nil? | ||
empty_content | ||
elsif @response.content_type == "application/json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to add support for JSON variants like application/x-json
, text/json
, or vendored JSON content types like application/vnd.github.v3.star+json
.
I added something similar last week in one of our core OpenAPI tooling methods last week here: https://github.com/readmeio/oas/blob/master/packages/tooling/src/operation.js#L62
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Since this PR is focused on empty response bodies and only moved the JSON code, I'm going to implement your suggestion in a separate feature. I've created a Trello card to keep track of it.
size: @response.content_length, | ||
text: Har::Collection.new(@filter, parsed_body).to_h.to_json} | ||
rescue | ||
pass_through_content |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call 👍
Some responses have no response body (e.g. an HTTP 204 response). `Rack::Response` handles this by returning `nil` when calling `#body`. The HAR spec mentions that `response.content.text` key is optional. However, it _does_ require the `response.content.mimeType` key. Based on discussion with the Readme.io team, we decided to send an empty string in this spot when there is no request body. The HAR spec is ambiguous about the `response.content.size` key. It mentions that it should be 0 for 304 responses (another scenario with no body) and -1 if unknown. I chose to set 0 for responses without a body since we do know the length and the spec specifically says to use 0 in some instances of no-body responses. While testing this code, I found a bug where attempting to read the body more than once failed since the IO object had not been rewound. While moving some of the existing JSON code around, I realized that some of it's code paths were untested so I added a test around invalid payloads.
eacc39e
to
f188a45
Compare
Bumps [jest](https://github.com/facebook/jest) from 25.1.0 to 25.2.4. - [Release notes](https://github.com/facebook/jest/releases) - [Changelog](https://github.com/facebook/jest/blob/master/CHANGELOG.md) - [Commits](jestjs/jest@v25.1.0...v25.2.4) Signed-off-by: dependabot-preview[bot] <[email protected]> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
🧰 What's being changed?
Some responses have no response body (e.g. an HTTP 204 response).
Rack::Response
handles this by returningnil
when calling#body
.The HAR spec mentions that
response.content.text
key is optional.However, it does require the
response.content.mimeType
key. Based ondiscussion with the Readme.io team, we decided to send an empty string in
this spot when there is no request body.
The HAR spec is ambiguous about the
response.content.size
key. Itmentions that it should be 0 for 304 responses (another scenario with no
body) and -1 if unknown. I chose to set 0 for responses without a body
since we do know the length and the spec specifically says to use 0
in some instances of no-body responses.
While testing this code, I found a bug where attempting to read the body
more than once failed since the IO object had not been rewound.
While moving some of the existing JSON code around, I realized that some
of it's code paths were untested so I added a test around invalid
payloads.
🧪 Testing
Create a simple Rack app that returns an empty body:
run it with:
and make a request to it:
Then expect to see the request show up in the Readme.io dashboard