mirror of
https://github.com/nodejs/node.git
synced 2025-08-15 13:48:44 +02:00
![]() This patch implements proxy support for HTTP and HTTPS clients and agents in the `http` and `https` built-ins`. When NODE_USE_ENV_PROXY is set to 1, the default global agent would parse the HTTP_PROXY/http_proxy, HTTPS_PROXY/https_proxy, NO_PROXY/no_proxy settings from the environment variables, and proxy the requests sent through the built-in http/https client accordingly. To support this, `http.Agent` and `https.Agent` now accept a few new options: - `proxyEnv`: when it's an object, the agent would read and parse the HTTP_PROXY/http_proxy, HTTPS_PROXY/https_proxy, NO_PROXY/no_proxy properties from it, and apply them based on the protocol it uses to send requests. This option allows custom agents to reuse built-in proxy support by composing options. Global agents set this to `process.env` when NODE_USE_ENV_PROXY is 1. - `defaultPort` and `protocol`: these allow setting of the default port and protocol of the agents. We also need these when configuring proxy settings and deciding whether a request should be proxied. Implementation-wise, this adds a `ProxyConfig` internal class to handle parsing and application of proxy configurations. The configuration is parsed during agent construction. When requests are made, the `createConnection()` methods on the agents would check whether the request should be proxied. If yes, they either connect to the proxy server (in the case of HTTP reqeusts) or establish a tunnel (in the case of HTTPS requests) through either a TCP socket (if the proxy uses HTTP) or a TLS socket (if the proxy uses HTTPS). When proxying HTTPS requests through a tunnel, the connection listener is invoked after the tunnel is established. Tunnel establishment uses the timeout of the request options, if there is one. Otherwise it uses the timeout of the agent. If an error is encountered during tunnel establishment, an ERR_PROXY_TUNNEL would be emitted on the returned socket. If the proxy server sends a errored status code, the error would contain an `statusCode` property. If the error is caused by timeout, the error would contain a `proxyTunnelTimeout` property. This implementation honors the built-in socket pool and socket limits. Pooled sockets are still keyed by request endpoints, they are just connected to the proxy server instead, and the persistence of the connection can be maintained as long as the proxy server respects connection/proxy-connection or persist by default (HTTP/1.1) PR-URL: https://github.com/nodejs/node/pull/58980 Refs: https://github.com/nodejs/node/issues/57872 Refs: https://github.com/nodejs/node/issues/8381 Refs: https://github.com/nodejs/node/issues/15620 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> |
||
---|---|---|
.. | ||
api | ||
api_assets | ||
changelogs | ||
contributing | ||
abi_version_registry.json | ||
eslint.config_partial.mjs | ||
full-white-stripe.jpg | ||
node-config-schema.json | ||
node.1 | ||
osx_installer_logo.png | ||
README.md | ||
template.html | ||
thin-white-stripe.jpg |
Node.js documentation style guide
This guide provides clear and concise instructions to help you create well-organized and readable documentation for the Node.js community. It covers organization, spelling, formatting, and more to ensure consistency and professionalism across all documents.
Table of contents
- General Guidelines
- Writing Style
- Punctuation
- Document Structure
- API Documentation
- Code Blocks
- Formatting
- Product and Project Naming
General guidelines
File naming
- Markdown Files: Use
lowercase-with-dashes.md
.- Use underscores only if they are part of the topic name (e.g.,
child_process
). - Some files, like top-level Markdown files, may be exceptions.
- Use underscores only if they are part of the topic name (e.g.,
Text wrapping
- Wrap documents at 120 characters per line to enhance readability and version control.
Editor configuration
- Follow the formatting rules specified in
.editorconfig
.- A plugin is available for some editors to enforce these rules.
Testing documentation
- Validate documentation changes using
make test-doc -j
orvcbuild test-doc
.
Writing style
Spelling and grammar
- Spelling: Use US spelling.
- Grammar: Use clear, concise language. Avoid unnecessary jargon.
Commas
- Serial Commas: Use serial commas for clarity.
- Example: apples, oranges, and bananas
Pronouns
- Avoid first-person pronouns (I, we).
- Exception: Use we recommend foo instead of foo is recommended.
Gender-neutral language
- Use gender-neutral pronouns and plural nouns.
- OK: they, their, them, folks, people, developers
- NOT OK: his, hers, him, her, guys, dudes
Terminology
- Use precise technical terms and avoid colloquialisms.
- Define any specialized terms or acronyms at first use.
Punctuation
Terminal punctuation
- Place inside parentheses or quotes if the content is a complete clause.
- Place outside if the content is a fragment of a clause.
Quotation marks
- Use double quotation marks for direct quotes.
- Use single quotation marks for quotes within quotes.
Colons and semicolons
- Use colons to introduce lists or explanations.
- Use semicolons to link closely related independent clauses.
Document structure
Headings
- Start documents with a level-one heading (
#
). - Use subsequent headings (
##
,###
, etc.) to organize content hierarchically.
Links
- Prefer reference-style links (
[a link][]
) over inline links ([a link](http://example.com)
).
Lists
- Use bullet points for unordered lists and numbers for ordered lists.
- Keep list items parallel in structure.
Tables
- Use tables to present structured information clearly. Ensure they are readable in plain text.
API documentation
YAML comments
- Update the YAML comments associated with the API, especially when introducing or deprecating an API.
Usage examples
- Provide a usage example or a link to an example for every function.
Parameter descriptions
- Clearly describe parameters and return values, including types and defaults.
- Example:
* `byteOffset` {integer} Index of first byte to expose. **Default:** `0`.
- Example:
Code blocks
Language-aware fences
-
Use language-aware fences (e.g.,
```js
) for code blocks.-
Info String: Use the appropriate info string from the following list:
Language Info String Bash bash
C c
CommonJS cjs
CoffeeScript coffee
Terminal Session console
C++ cpp
Diff diff
HTTP http
JavaScript js
JSON json
Markdown markdown
EcmaScript mjs
Powershell powershell
R r
Plaintext text
TypeScript typescript
-
Use
text
for languages not listed until their grammar is added toremark-preset-lint-node
.
-
Code comments
- Use comments to explain complex logic within code examples.
- Follow the standard commenting style of the respective language.
Formatting
Escaping characters
- Use backslash-escaping for underscores, asterisks, and backticks:
\_
,\*
,\`
.
Naming conventions
- Constructors: Use PascalCase.
- Instances: Use camelCase.
- Methods: Indicate methods with parentheses:
socket.end()
instead ofsocket.end
.
Function arguments and returns
- Arguments:
Example:* `name` {type|type2} Optional description. **Default:** `value`.
* `byteOffset` {integer} Index of first byte to expose. **Default:** `0`.
- Returns:
Example:* Returns: {type|type2} Optional description.
* Returns: {AsyncHook} A reference to `asyncHook`.
Product and project naming
Official styling
- Use official capitalization for products and projects.
- OK: JavaScript, Google's V8
- NOT OK: Javascript, Google's v8
Node.js references
- Use Node.js instead of Node, NodeJS, or similar variants.
- For the executable,
node
is acceptable.
- For the executable,
Version references
- Use Node.js and the version number in prose. Do not prefix the version number with v.
- OK: Node.js 14.x, Node.js 14.3.1
- NOT OK: Node.js v14
For topics not addressed here, please consult the Microsoft Writing Style Guide.