Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Fix] Content-Length header on explicit null body response #1528

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

[Fix] Content-Length header on explicit null body response #1528

wants to merge 2 commits into from

Conversation

@ognjenjevremovic
Copy link

@ognjenjevremovic ognjenjevremovic commented Mar 18, 2021 •
edited
Loading

Fixes #1525

Changes

  • Set the context length value to 0 for explicit null body response(s),
  • Provided the necessary set of tests for this change,
  • Maintained the test coverage of 100%.

Checklist

After the changes I ensured that:

  • no stylistic or unwanted errors are present, by running npm run lint from the root directory,
  • no tests are failing, by running npm run test from the root directory,
  • build passes with no issues, by running npm run build from the root directory.

Done

  • Added/updated unit tests for this change
  • Included links to related issues/PRs

Ognjen Jevremovic added 2 commits March 18, 2021 18:31
fix: 🐛 Set content-length header to explicit-null-body
e030c88 
Responding with an empty message, that does not have a Transfer-Encoding
header field set, a Content-Length header field is used to provide the
anticipated size for a potential payload body.The Content-Length header
should be provided in such case(s), so that the user agent does not fail
the request / response cycle.

✅ Closes: koajs#1525
fix: 🐛 explicit-null-body content-length header tests
8bf70d0 
Extend upon existing and provide new unit tests, for asserting the
content-length header presence and value on the explicit null body
responses.

✅ Closes: koajs#1525
@codecov
Copy link

codecov bot commented Mar 18, 2021 •
edited
Loading

Codecov Report

Merging #1528 (8bf70d0) into master (eb51cf5) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##            master     #1528   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            4         4           
  Lines          489       490    +1     
  Branches       136       136           
=========================================
+ Hits           489       490    +1
Impacted Files Coverage Δ
lib/application.js 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb51cf5...8bf70d0. Read the comment docs.

3imed-jaberi
3imed-jaberi approved these changes Apr 8, 2021
View reviewed changes
Copy link
Member

@3imed-jaberi 3imed-jaberi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm +1

jkomyno
jkomyno approved these changes Apr 16, 2021
View reviewed changes
Copy link

@jkomyno jkomyno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit seems legitimate.
But why is it necessary to test the absence of the 'transfer-encoding' header?

@ognjenjevremovic
Copy link
Author

ognjenjevremovic commented Apr 22, 2021

@jkomyno I apologize for getting back late. I've been offline for a week, due to the health issues.

I've referenced the RFC7230.
It seems that the use case applies to user agents instead (I guess I skimmed way too fast through the text and misunderstood the writing). It does seems redundant, especially in test cases but I guess I wanted to follow the recommended way of handling the response headers (however, now I see I got them confused for the request headers instead).

A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body.

Do you think the assertion should be removed?
I can provide a commit for getting rid of the unnecessary header check.

@ognjenjevremovic
Copy link
Author

ognjenjevremovic commented May 29, 2021

Any updates on the MR?

@jonathanong
Copy link
Member

jonathanong commented Jun 28, 2021

@ognjenjevremovic I will merge it if I have time to do a release. hopefully someone else will get to it before I do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jonathanong jonathanong jonathanong approved these changes

@3imed-jaberi 3imed-jaberi 3imed-jaberi approved these changes

+1 more reviewer

@jkomyno jkomyno jkomyno approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@ognjenjevremovic @jonathanong @jkomyno @3imed-jaberi