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

doc: improve http.setHeader and getHeader typeinfo #19902

Closed
wants to merge 5 commits into from
Closed

doc: improve http.setHeader and getHeader typeinfo #19902

wants to merge 5 commits into from

Conversation

Flarna
Copy link
Member

@Flarna Flarna commented Apr 9, 2018

http.setHeader() coerces input values to strings.
http.getHeader() returns the type as passed to setHeader().

Fixes: #13825

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. http Issues or PRs related to the http subsystem. labels Apr 9, 2018
@Flarna Flarna changed the title doc: improve http.setHeader and getHeader typinfo doc: improve http.setHeader and getHeader typeinfo Apr 9, 2018
http.setHeader() coerces input values.
http.getHeader() returns the type as passed to setHeader()

fixes #13825
@Trott
Copy link
Member

Trott commented Apr 9, 2018

@nodejs/documentation @nodejs/http

doc/api/http.md Outdated
@@ -587,9 +587,11 @@ added: v1.6.0
-->

* `name` {string}
* Returns: {string}
* Returns: {string, string[]} - type as set via `setHeader()`
Copy link
Member

@Trott Trott Apr 9, 2018

Choose a reason for hiding this comment

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

The type as set via part seems out of place. If the information is critical, it can be included in the text below.

Use a | to separate the two possible return types, not a comma. (This is to be consistent with our documentation elsewhere.)

Copy link
Member

Choose a reason for hiding this comment

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

@vsemozhetbyt Yes, thanks, updated!

Trott
Trott previously requested changes Apr 9, 2018
Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

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

Thanks for the PR! A few suggested changes...

doc/api/http.md Outdated
@@ -1210,7 +1212,8 @@ added: v0.4.0

Sets a single header value for implicit headers. If this header already exists
in the to-be-sent headers, its value will be replaced. Use an array of strings
here to send multiple headers with the same name.
here to send multiple headers with the same name. Values are coerced to
strings if needed during transmission.
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps just this for the last sentence? Non-string values will be coerced to strings.

doc/api/http.md Outdated

Reads out a header on the request. Note that the name is case insensitive.
The return value is that one set via `setHeader()` as coercing to string
happens during transmission.
Copy link
Member

@Trott Trott Apr 9, 2018

Choose a reason for hiding this comment

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

This sentence is a bit difficult to understand. How about this instead:

The type of the return value depends on the arguments provided to `setHeader()`.

Also, setHeaders() should be a link to that function in the docs.

Copy link
Member

Choose a reason for hiding this comment

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

@vsemozhetbyt Whoops, yes, thanks for the correction!

@BridgeAR BridgeAR requested a review from vsemozhetbyt April 9, 2018 23:30
@Flarna
Copy link
Member Author

Flarna commented Apr 10, 2018

Updated.
Just for the notes. I considered also to change the http implementation to match the docu by doing the conversion to strings in setHeader. But I found that current behavior is verified in some test and I fear it would break at least one app/module out there.

doc/api/http.md Outdated

Example:
```js
const contentType = request.getHeader('Content-Type');
request.setHeader('content-type', 'text/html');
request.setHeader('Content-Length': Buffer.byteLength(body));
Copy link
Contributor

Choose a reason for hiding this comment

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

: -> ,

doc/api/http.md Outdated
const contentType = request.getHeader('Content-Type');
request.setHeader('content-type', 'text/html');
request.setHeader('Content-Length': Buffer.byteLength(body));
request.setHeader('Set-Cookie', ['type=ninja', 'language=javascript'])
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing semicolon.

doc/api/http.md Outdated
request.setHeader('content-type', 'text/html');
request.setHeader('Content-Length': Buffer.byteLength(body));
request.setHeader('Set-Cookie', ['type=ninja', 'language=javascript'])
const contentType = request.getHeader('Content-Type'); // contentType is 'text/html'
Copy link
Contributor

Choose a reason for hiding this comment

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

We lint code examples in docs, so these 3 lines will violate max-len rule (they exceed 80 characters length). The comments may be moved to their own lines.

doc/api/http.md Outdated
request.setHeader('Content-Length': Buffer.byteLength(body));
request.setHeader('Set-Cookie', ['type=ninja', 'language=javascript'])
const contentType = request.getHeader('Content-Type'); // contentType is 'text/html'
const contentLength = request.getHeader('Content-Length'); // contentLength is of type number
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is true, should the parameter types be updated? Can we define the whole possible set there?

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, it's javascript so mostly everything is coerced to a string (even undefined). So actually setHeader() accepts any type and as a result getHeader() returns any type as it is a pass through.

Copy link
Contributor

Choose a reason for hiding this comment

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

So maybe we can use {any} there? @Trott, what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

So maybe we can use {any} there? @Trott, what do you think?

Works for me. Easy enough to update it to something else if we discover this confuses a lot of people. I don't think it will, though.

@vsemozhetbyt
Copy link
Contributor

@MoonBall
Copy link
Member

MoonBall commented Apr 10, 2018

I considered also to change the http implementation to match the docu by doing the conversion to strings in setHeader.

@Flarna The current behavior is expected. Non-string values will be coerced to strings in order to transmit them.

doc/api/http.md Outdated
@@ -587,13 +587,24 @@ added: v1.6.0
-->

* `name` {string}
* Returns: {string}
* Returns: {string|string[]}
Copy link
Member

@MoonBall MoonBall Apr 10, 2018

Choose a reason for hiding this comment

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

Should this be * Returns: {any}? Because

The type of the return value depends on the arguments provided to [response.setHeader()][].

Copy link
Member Author

@Flarna Flarna Apr 10, 2018

Choose a reason for hiding this comment

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

Should we use any also for setHeader then?
It is allowed and works as long as it translates to a string on the fly. It would be strange to say getHeader returns what was provided to setHeader but doc says setHeader accepts only string|string[] but getHeader returns any.
Something like stringifyable would be best match but this is no type.

doc/api/http.md Outdated
@@ -1210,7 +1221,8 @@ added: v0.4.0

Sets a single header value for implicit headers. If this header already exists
in the to-be-sent headers, its value will be replaced. Use an array of strings
here to send multiple headers with the same name.
here to send multiple headers with the same name. Non-string values will be
coerced to strings.
Copy link
Member

@MoonBall MoonBall Apr 10, 2018

Choose a reason for hiding this comment

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

Non-string values will be coerced to strings in order to transmit them.

Copy link
Member Author

@Flarna Flarna Apr 10, 2018

Choose a reason for hiding this comment

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

They are coerced to strings already during set in validateHeader() => checkInvalidHeaderChar() but the result is not stored. if it fails or holds invalid chars caller gets an Error. During sending they are converted once more.

Copy link
Member

@Trott Trott Apr 10, 2018

Choose a reason for hiding this comment

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

Ooof, I see the subtlety here now. Maybe be super explicit?

Non-string values will be stored without modification. Therefore, `getHeader()`
may return non-string values. However, the non-string values will be converted
to strings for network transmission.

Something like that maybe (but wrapped at 80 chars instead whatever I'm wrapping at above)?

@Flarna
Copy link
Member Author

Flarna commented Apr 10, 2018

Updated once more with hints from @Trott. I noticed also that I mixed up request/response APIs. Now both of the should be updated.

doc/api/http.md Outdated
@@ -616,11 +627,14 @@ added: v1.6.0
-->

* `name` {string}
* `value` {string}
* `value` {string|string[]}
Copy link
Member

Choose a reason for hiding this comment

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

The type of value should be any.

Copy link
Member

Choose a reason for hiding this comment

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

The response.setHeader() also needs to be modified.

Copy link
Member

Choose a reason for hiding this comment

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

LGTM if the above two small nits are fixed. @Flarna

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Apr 12, 2018
@trivikr
Copy link
Member

trivikr commented Apr 12, 2018

BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Apr 13, 2018
http.setHeader() coerces input values.
http.getHeader() returns the type as passed to setHeader().

PR-URL: nodejs#19902
Fixes: nodejs#13825
Reviewed-By: Chen Gang <gangc.cxy@foxmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@BridgeAR
Copy link
Member

Landed in 50e9f8d 🎉

@BridgeAR BridgeAR closed this Apr 13, 2018
@Flarna Flarna deleted the http_doc_getheader branch April 13, 2018 18:35
jasnell pushed a commit that referenced this pull request Apr 16, 2018
http.setHeader() coerces input values.
http.getHeader() returns the type as passed to setHeader().

PR-URL: #19902
Fixes: #13825
Reviewed-By: Chen Gang <gangc.cxy@foxmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
BridgeAR pushed a commit to BridgeAR/node that referenced this pull request May 1, 2018
http.setHeader() coerces input values.
http.getHeader() returns the type as passed to setHeader().

PR-URL: nodejs#19902
Fixes: nodejs#13825
Reviewed-By: Chen Gang <gangc.cxy@foxmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. doc Issues and PRs related to the documentations. http Issues or PRs related to the http subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants