doc: update http.md for consistency #10715

lance · 2017-01-09T17:59:21Z

The HTTP Keep-Alive text was inconsistent. These changes follow the
following rules

When referring to flag used in code, it should always be written using
backticks and in camel case. E.g. keepAlive.
When referring to the mechanism Keep-Alive functionality as described
in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the
use of backticks.
When referring to the request header, it should always use backticks
and be written as Connection: keep-alive.

This commit also includes some changes to how http.Agent is
referenced. When Agent is used as a reference to an object or
instance, backticks should always be used.

Left somewhat unresolved is how to determine when to use "agent"
vs. "Agent". At the moment, the API documentation typically uses
"agent" when referring to a generic instance, and either http.Agent or
Agent when referring to a specific instance. But it's not really 100%
clear. I wonder if it would be best to just always use Agent.

Ref: #10614
Fixes: #10567

Checklist

documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

doc

The HTTP Keep-Alive text was inconsistent. These changes follow the following rules * When referring to flag used in code, it should always be written using backticks and in camel case. E.g. `keepAlive`. * When referring to the mechanism Keep-Alive functionality as described in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the use of backticks. * When referring to the request header, it should always use backticks and be written as `Connection: keep-alive`. This commit also includes some changes to how `http.Agent` is referenced. When `Agent` is used as a reference to an object or instance, backticks should always be used. Left somewhat unresolved is how to determine when to use "agent" vs. "`Agent`". At the moment, the API documentation typically uses "agent" when referring to a generic instance, and either `http.Agent` or `Agent` when referring to a specific instance. But it's not really 100% clear. I wonder if it would be best to just always use `Agent`. Ref: #10614 Fixes: #10567

mscdex · 2017-01-09T18:09:23Z

doc/api/http.md

+this option.
+
+If you opt into using HTTP Keep-Alive, you can create an `Agent` instance,
+providing `{ keepAlive: true }` among the constructor options. (See the


How about just link 'constructor options' here instead of having the extra '(See the constructor options.)'

mscdex · 2017-01-09T18:10:46Z

doc/api/http.md

+If you opt into using HTTP Keep-Alive, you can create an `Agent` instance,
+providing `{ keepAlive: true }` among the constructor options. (See the
+[constructor options][].) The `Agent` will then keep unused sockets in a
+pool for later use.  They will be explicitly marked so as to not keep the


Perhaps 'They' could be clarified here? It's not immediately clear if it's referring to the Agent instance or the unused sockets.

It is the socket that is unrefed here, right? Not the agent itself. Which also makes me wonder if unref should be mentioned here, or if that's too much detail.

I would probably just replace 'They' with 'The unused sockets'.

mscdex · 2017-01-09T18:11:30Z

doc/api/http.md

+pool for later use.  They will be explicitly marked so as to not keep the
+Node.js process running. However, it is still a good idea to explicitly
+[`destroy()`][] HTTP Keep-Alive agents when they are no longer in use, so that
+the Sockets will be shut down.


s/Sockets/sockets/

mscdex · 2017-01-09T18:11:56Z

doc/api/http.md

+
+If you opt into using HTTP Keep-Alive, you can create an `Agent` instance,
+providing `{ keepAlive: true }` among the constructor options. (See the
+[constructor options][].) The `Agent` will then keep unused sockets in a


s/`Agent`/agent/

mscdex · 2017-01-09T18:13:21Z

doc/api/http.md

+[`destroy()`][] HTTP Keep-Alive agents when they are no longer in use, so that
+the Sockets will be shut down.
+
+Sockets are removed from the `Agent`'s pool when the socket emits either


s/the `Agent`'s/an agent's/

mscdex · 2017-01-09T18:14:40Z

doc/api/http.md

@@ -179,8 +179,8 @@ added: v0.11.4
 * Returns: {String}

 Get a unique name for a set of request options, to determine whether a
-connection can be reused.  In the http agent, this returns
-`host:port:localAddress`.  In the https agent, the name includes the
+connection can be reused.  In the HTTP agent, this returns


s/In the HTTP/For an HTTP/

mscdex · 2017-01-09T18:14:50Z

doc/api/http.md

-connection can be reused.  In the http agent, this returns
-`host:port:localAddress`.  In the https agent, the name includes the
+connection can be reused.  In the HTTP agent, this returns
+`host:port:localAddress`.  In the HTTPS agent, the name includes the


s/In the HTTPS/For an HTTPS/

mscdex · 2017-01-09T18:16:38Z

doc/api/http.md

     `Connection: close`.
  * `createConnection` {Function} A function that produces a socket/stream to
-    use for the request when the `agent` option is not used. This can be used to
-    avoid creating a custom Agent class just to override the default
+    use for the request when the `Agent` option is not used. This can be used to


This shouldn't be changed, it's referring to the agent http.request() option above.

sam-github

This needs work:

   * `keepAlive` {Boolean} Keep sockets around in a pool to be used by
     other requests in the future. Default = `false`
   * `keepAliveMsecs` {Integer} When using HTTP KeepAlive, how often

The first bullet's keepAlive is what is referred to in the second bullet, but that is not at all clear.

If the keepAlive option is supposed to mean "HTTP KeepAlive" (note inconsistency in hyphenation, needs fixing), then it should self-describe itself as "HTTP Keep-Alive" so its completely clear!

However, given that there are THREE keep alive behaviours discussed in this PR:

the Agent's, aka "HTTP keep-alive", wherein it keeps unused tcp sockets around for possible use later
HTTP's keep-alive, "Connection: keep-alive", which allows the TCP connection to be reused for more HTTP requests
TCP keep-alive, SOL_KEEPALIVE (better called "kill fast" not "keep alive", but whatever), which causes TCP sockets to be removed faster from the pool if the network or HTTP server becomes unreachable

It needs to crystal clear which one is referred to at all times, they need to be hyphentated consistently, and I submit that using the phrase "HTTP keep alive" for a keep alive that is not, in fact, the one described in the HTTP protocol docs is not a good idea.

sam-github · 2017-01-09T18:53:33Z

doc/api/http.md

+require developers to manually close HTTP clients when using
+this option.
+
+If you opt into using HTTP Keep-Alive, you can create an `Agent` instance,


so "HTTP Keep-Alive" is different from "Connection: keep-alive"? I thought that latter was an HTTP header, and is HTTP keep-alive? But you said keep alive is the default above, but here you say you have to opt-in. I'm confused.

read more, I think what you are calling "HTTP Keep-Alive" here would be better described as "Agent Keep-Alive", or something of the sort, its a purely Agent thing to keep HTTP connections around, even when unused. Unlike HTTP Keep-Alive, which is to allow multiple requests over a single TCP socket.

These are valid points. To be clear, for the most part, I haven't changed the body of the text beyond trying to be consistent about styling, hyphenation and capitalization. These two or three confusing paragraphs definitely need work. To be honest, I didn't spend a huge amount of time reading the body of the text for overall context. Rather, I was looking for punctuation, styling and capitalization inconsistencies.

If it makes sense to improve the clarity of this content as you describe here, I can think on it and add it to the PR. But that was not really the original purpose here.

lance · 2017-01-09T20:50:46Z

@sam-github I agree the new Agent options need work. :)

keepAlive {Boolean} Keep sockets around in a pool to be used by other requests in the future. Default = false

This means both that sockets will be kept around, and also that HTTP Keep-Alive will be active on the sockets. This is somewhat redundant, since with HTTP 1.1, Keep-Alive is active by default and must explicitly be turned off. It's definitely confusing that this single option means both socket pooling AND HTTP Keep-Alive, which itself is unnecessary, but does ultimately result in the SO_KEEPALIVE flag on the underlying socket.

But I don't think adding another option here would make things better. I would say that it's simply a side effect of the flag that HTTP Keep-Alive (and therefore TCP SO_KEEPALIVE) are enabled.

keepAliveMsecs {Integer} When using HTTP KeepAlive, how often to send TCP KeepAlive packets over sockets being kept alive. Default = 1000. Only relevant if keepAlive is set to true.

When using HTTP Keep-Alive as described in this document, the TCP SO_KEEPALIVE flag will be set in lib_uv via tcp_wrap.cc. But I really think it's unnecessary to include all of this detail in the documentation.

How about this:

keepAlive {Boolean} Keep sockets around in a pool to be used by other requests in the future. In addition to pooling sockets, this option also enables HTTP Keep-Alive by default on all connections. Default = false

keepAliveMsecs {Integer} When using the keepAlive option, this specifies how often to send TCP SO_KEEPALIVE Ack packets. Default = 1000. Only relevant if keepAlive is true.

sam-github · 2017-01-09T21:01:56Z

This means both that sockets will be kept around, and also that HTTP Keep-Alive will be active on the sockets.

Agree, and the docs should say so right there (they do not ATM).

But I don't think adding another option here would make things better.

I did not and do not suggest any more options, did you get that impression?

Implementing HTTP Keep Alive does not require setting SOL_KEEPALIVE, and I for one had no idea that causing Connection: keep-alive to be set also had the side effect of setting SOL_KEEPALIVE. If it does that, it needs to be documented.

But I really think it's unnecessary to include all of this detail in the documentation.

I don't agree at all. Setting SOL_KEEPALIVE has observable effects on the sockets, effects that are predictable if we know its set.

Knowing that Connection: keep-alive is set is important for trouble-shooting, and to avoid people asking whether it is or is not set.

My point that "HTTP Keep-Alive" in the docs sometimes refers to https://en.wikipedia.org/wiki/HTTP_persistent_connection ("HTTP keep-alive"), or sometimes to the agent .keepAlive option (and yes, the latter also causes the Connection: keep-alive to be set per-socket).

It needs to be more clear.

sam-github · 2017-01-09T21:06:41Z

OK, I see where you are coming from, you just want to do a little cleanup. That is OK.

However, from PR description:

When referring to the mechanism Keep-Alive functionality as described
in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the
use of backticks.

But from PR:

HTTP Keep-Alive agents when they are no longer in use

Here, HTTP Keep-Alive refers to an agent's pooling behaviour, not to the HTTP RFC, so the terminology is not cleaned up.

lance · 2017-01-09T21:08:02Z

Agree, and the docs should say so righ there (they do not ATM).

So, I can do this - see my earlier note about the original purpose of the PR. I don't mind expanding it, but to be clear this wasn't the original purpose. :)

I did not and do not suggest any more options, did you get that impression?

No not really. I just wanted to be clear about my feelings on it in case we went down that path.

Regarding SO_KEEPALIVE vs. HTTP Keep-Alive, I think it might be useful for someone with more knowledge of the internals to chime in here. I only discovered this connection today because I wanted to understand what was really going on, so I read the code. It may be that I misread, or it may be that the docs need a real overhaul.

lance · 2017-01-10T21:47:21Z

@sam-github after spending even more time reading specs and looking at the existing code, I agree with you both about the fact that the docs are confusing, and also that including low-level detail is relevant and important. I will add some more commits this week that hopefully clarify a bit more.

sam-github · 2017-01-11T01:00:48Z

@lance thanks for your patience, looking forward to the new docs

lance · 2017-01-12T18:26:13Z

@sam-github Just an update - I have been reading the code all morning, and the keep alive logic is mind boggling, shared between _http_outgoing.js, _http_agent.js, _http_client.js, and net.js. If I'm reading it correctly, as far as clients go, by default, we're not implementing HTTP/1.1 persistence.

The HTTP/1.1 spec says,

A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.

Both the http.globalAgent and the default constructor behave so that multiple, simultaneous requests will reuse an existing connection, but once the Agent instance has no more pending requests for a given host/port, the socket is destroyed, instead of assuming the server will maintain the connection.

But really, I wonder if this is the intended behavior. It's not necessarily broken, but seems like an odd default. That, combined with the fact that the default also does not pool sockets -- you must specify keepAlive: true to enable this -- makes it seems like the Agent doesn't do much on its own, unless expressly created/configured to do so.

To summarize. If I read it correctly, the default behavior for all HTTP client requests using an Agent (even the default http._globalAgent is to:

Always send HTTP/1.0Connection: keep-alive headers. See: https://github.com/nodejs/node/blob/master/lib/_http_outgoing.js#L276-L279
Destroy socket connections when there are no more pending requests for a given host/port. See: https://github.com/nodejs/node/blob/master/lib/_http_agent.js#L47-L81
Not implement HTTP/1.1 persistent connections, since sockets are destroyed by default (see above)
Not pool socket connections, unless there are multiple, simultaneous requests to the same host/port (see above)
To use connection pooling, you must specify { keepAlive: true } as a constructor option in a new Agent
When using connection pooling, HTTP/1.0 connection persistence is enabled using the Connection: keep-alive header. See above re: always sending Connection: keep-alive
When using connection pooling, and therefore also HTTP/1.0 connection persistence via Connection: keep-alive headers (because you can't have one without the other in this implementation), TCP SO_KEEPALIVE is used via lib_uv's uv_tcp_keepalive function. See: https://github.com/nodejs/node/blob/master/lib/_http_agent.js#L73, https://github.com/nodejs/node/blob/master/lib/net.js#L368, and https://github.com/nodejs/node/blob/master/src/tcp_wrap.cc#L161
None of this matters at all if you provide a createConnection function to the http.request() function.

I would love for someone with better knowledge of the intent to chime in here. My reading of the code could be wrong. But if it's correct, it sure is confusing and I find it hard to believe this is the true intent.

/cc @nodejs/collaborators @nodejs/documentation

lance · 2017-01-12T18:28:18Z

Adding the 'net' label for now, since it's not really clear if this is purely a documentation issue.

mscdex · 2017-01-12T18:32:14Z

@lance What you're just now discussing (the actual behavior of the http implementation) is unrelated to the original issue, which is the styling of the documentation. So I'm not sure that this (the original change) is related to net.

lance · 2017-01-12T19:14:32Z

@mscdex fair enough. Label removed. Do you think what I've described here is worthy of a separate issue? And do you have the knowledge to say whether or not my understanding is correct?

mscdex · 2017-01-12T19:33:46Z

@lance I would say it's a separate issue worth discussing. I am not very familiar overall with the HTTP Keep-Alive implementation in node, so I can't really comment on that.

lance · 2017-01-24T21:41:48Z

@sam-github @mscdex I've incorporated your feedback. Sorry about the delay, I've been traveling quite a bit. I think it's just about there. Have a look when you can. Thanks.

sam-github · 2017-01-24T21:55:12Z

PTAL @mscdex @lpinca

lance · 2017-01-25T15:27:07Z

Landed in 3b9e8ad

lance · 2017-01-25T15:27:30Z

This has the lts-watch-v6.x tag. Should I go ahead and backport it?

The HTTP Keep-Alive text was inconsistent. These changes follow the following rules * When referring to flag used in code, it should always be written using backticks and in camel case. E.g. `keepAlive`. * When referring to the mechanism Keep-Alive functionality as described in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the use of backticks. * When referring to the request header, it should always use backticks and be written as `Connection: keep-alive`. This commit also includes some changes to how `http.Agent` is referenced. When `Agent` is used as a reference to an object or instance, backticks should always be used. And lastly, the documentation about `Agent` behavior around HTTP Keep-Alive has been clarified and improved. Fixes: #10567 PR-URL: #10715 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

targos · 2017-01-25T15:50:36Z

That shouldn't be necessary. The bot adds the label only when the change applies cleanly.

The HTTP Keep-Alive text was inconsistent. These changes follow the following rules * When referring to flag used in code, it should always be written using backticks and in camel case. E.g. `keepAlive`. * When referring to the mechanism Keep-Alive functionality as described in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the use of backticks. * When referring to the request header, it should always use backticks and be written as `Connection: keep-alive`. This commit also includes some changes to how `http.Agent` is referenced. When `Agent` is used as a reference to an object or instance, backticks should always be used. And lastly, the documentation about `Agent` behavior around HTTP Keep-Alive has been clarified and improved. Fixes: #10567 PR-URL: #10715 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The HTTP Keep-Alive text was inconsistent. These changes follow the following rules * When referring to flag used in code, it should always be written using backticks and in camel case. E.g. `keepAlive`. * When referring to the mechanism Keep-Alive functionality as described in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the use of backticks. * When referring to the request header, it should always use backticks and be written as `Connection: keep-alive`. This commit also includes some changes to how `http.Agent` is referenced. When `Agent` is used as a reference to an object or instance, backticks should always be used. And lastly, the documentation about `Agent` behavior around HTTP Keep-Alive has been clarified and improved. Fixes: nodejs#10567 PR-URL: nodejs#10715 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

Krinkle · 2017-02-01T19:20:14Z

doc/api/http.md

+    outstanding requests, so they can be used for future requests without
+    having to reestablish a TCP connection. Default = `false`
+  * `keepAliveMsecs` {Integer} When using the `keepAlive` option, specifies
+    the [initial delay](#net_socket_setkeepalive_enable_initialdelay)


This reference is broken. There is no such anchor on the http page. This should link to net.html instead.

Fixed in pull #11108.

Follows-up pull nodejs#10715.

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

Refs: nodejs#10715 PR-URL: nodejs#11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The HTTP Keep-Alive text was inconsistent. These changes follow the following rules * When referring to flag used in code, it should always be written using backticks and in camel case. E.g. `keepAlive`. * When referring to the mechanism Keep-Alive functionality as described in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the use of backticks. * When referring to the request header, it should always use backticks and be written as `Connection: keep-alive`. This commit also includes some changes to how `http.Agent` is referenced. When `Agent` is used as a reference to an object or instance, backticks should always be used. And lastly, the documentation about `Agent` behavior around HTTP Keep-Alive has been clarified and improved. Fixes: #10567 PR-URL: #10715 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

jasnell · 2017-03-08T22:45:02Z

Landed in v6. This will need a backport PR to land in v4

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

The HTTP Keep-Alive text was inconsistent. These changes follow the following rules * When referring to flag used in code, it should always be written using backticks and in camel case. E.g. `keepAlive`. * When referring to the mechanism Keep-Alive functionality as described in the HTTP 1.1 RFC, it is written as 'HTTP Keep-Alive', without the use of backticks. * When referring to the request header, it should always use backticks and be written as `Connection: keep-alive`. This commit also includes some changes to how `http.Agent` is referenced. When `Agent` is used as a reference to an object or instance, backticks should always be used. And lastly, the documentation about `Agent` behavior around HTTP Keep-Alive has been clarified and improved. Fixes: #10567 PR-URL: #10715 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

nodejs-github-bot added doc Issues and PRs related to the documentations. http Issues or PRs related to the http subsystem. lts-watch-v6.x labels Jan 9, 2017

lance mentioned this pull request Jan 9, 2017

Changes to http.md #10614

Closed

2 tasks

mscdex reviewed Jan 9, 2017

View reviewed changes

doc: incorporate feedback into http.md

cfeedac

sam-github suggested changes Jan 9, 2017

View reviewed changes

sam-github mentioned this pull request Jan 9, 2017

References to an "KeepAlive" flag in the http.Agent constructor, when it is actually "keepAlive" #10567

Closed

fabiancook mentioned this pull request Jan 10, 2017

doc: keepAliveMsecs refers to an initial delay not interval #10702

Closed

2 tasks

lance added the net Issues and PRs related to the net subsystem. label Jan 12, 2017

lance removed the net Issues and PRs related to the net subsystem. label Jan 12, 2017

sam-github approved these changes Jan 24, 2017

View reviewed changes

lpinca approved these changes Jan 25, 2017

View reviewed changes

lance closed this Jan 25, 2017

italoacasas mentioned this pull request Jan 29, 2017

v7.5.0 proposal #11062

Merged

Krinkle reviewed Feb 1, 2017

View reviewed changes

Krinkle added a commit to Krinkle/node that referenced this pull request Feb 1, 2017

doc: fix "initial delay" link in http.md

e1410a6

Follows-up pull nodejs#10715.

Krinkle mentioned this pull request Feb 1, 2017

doc: fix "initial delay" link in http.md #11108

Closed

lpinca pushed a commit that referenced this pull request Feb 4, 2017

doc: fix "initial delay" link in http.md

33b4e47

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

italoacasas pushed a commit to italoacasas/node that referenced this pull request Feb 5, 2017

doc: fix "initial delay" link in http.md

8cdd600

Refs: nodejs#10715 PR-URL: nodejs#11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

italoacasas pushed a commit to italoacasas/node that referenced this pull request Feb 14, 2017

doc: fix "initial delay" link in http.md

ae33a15

Refs: nodejs#10715 PR-URL: nodejs#11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

krydos pushed a commit to krydos/node that referenced this pull request Feb 25, 2017

doc: fix "initial delay" link in http.md

390e452

Refs: nodejs#10715 PR-URL: nodejs#11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

jasnell pushed a commit that referenced this pull request Mar 7, 2017

doc: fix "initial delay" link in http.md

af780c9

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

jasnell pushed a commit that referenced this pull request Mar 7, 2017

doc: fix "initial delay" link in http.md

c47c764

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

jasnell added the dont-land-on-v4.x label Mar 8, 2017

MylesBorins pushed a commit that referenced this pull request Mar 9, 2017

doc: fix "initial delay" link in http.md

89d3090

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

MylesBorins mentioned this pull request Mar 9, 2017

v6.10.1 proposal #11759

Merged

MylesBorins pushed a commit that referenced this pull request Mar 9, 2017

doc: fix "initial delay" link in http.md

e90317d

Refs: #10715 PR-URL: #11108 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

doc: update http.md for consistency #10715

doc: update http.md for consistency #10715

lance commented Jan 9, 2017

mscdex Jan 9, 2017

mscdex Jan 9, 2017

lance Jan 9, 2017

mscdex Jan 9, 2017

mscdex Jan 9, 2017

mscdex Jan 9, 2017 •

edited

Loading

mscdex Jan 9, 2017

mscdex Jan 9, 2017 •

edited

Loading

mscdex Jan 9, 2017 •

edited

Loading

mscdex Jan 9, 2017 •

edited

Loading

sam-github left a comment

sam-github Jan 9, 2017

sam-github Jan 9, 2017

lance Jan 9, 2017 •

edited

Loading

lance commented Jan 9, 2017

sam-github commented Jan 9, 2017 •

edited

Loading

sam-github commented Jan 9, 2017

lance commented Jan 9, 2017

lance commented Jan 10, 2017

sam-github commented Jan 11, 2017

lance commented Jan 12, 2017 •

edited

Loading

lance commented Jan 12, 2017

mscdex commented Jan 12, 2017 •

edited

Loading

lance commented Jan 12, 2017

mscdex commented Jan 12, 2017 •

edited

Loading

lance commented Jan 24, 2017

sam-github commented Jan 24, 2017

lance commented Jan 25, 2017 •

edited

Loading

lance commented Jan 25, 2017

targos commented Jan 25, 2017 •

edited

Loading

Krinkle Feb 1, 2017 •

edited

Loading

jasnell commented Mar 8, 2017

doc: update http.md for consistency #10715

doc: update http.md for consistency #10715

Conversation

lance commented Jan 9, 2017

Checklist

Affected core subsystem(s)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mscdex Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mscdex Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

mscdex Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

mscdex Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

sam-github left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lance Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

lance commented Jan 9, 2017

sam-github commented Jan 9, 2017 • edited Loading

sam-github commented Jan 9, 2017

lance commented Jan 9, 2017

lance commented Jan 10, 2017

sam-github commented Jan 11, 2017

lance commented Jan 12, 2017 • edited Loading

lance commented Jan 12, 2017

mscdex commented Jan 12, 2017 • edited Loading

lance commented Jan 12, 2017

mscdex commented Jan 12, 2017 • edited Loading

lance commented Jan 24, 2017

sam-github commented Jan 24, 2017

lance commented Jan 25, 2017 • edited Loading

lance commented Jan 25, 2017

targos commented Jan 25, 2017 • edited Loading

Krinkle Feb 1, 2017 • edited Loading

Choose a reason for hiding this comment

jasnell commented Mar 8, 2017

mscdex Jan 9, 2017 •

edited

Loading

mscdex Jan 9, 2017 •

edited

Loading

mscdex Jan 9, 2017 •

edited

Loading

mscdex Jan 9, 2017 •

edited

Loading

lance Jan 9, 2017 •

edited

Loading

sam-github commented Jan 9, 2017 •

edited

Loading

lance commented Jan 12, 2017 •

edited

Loading

mscdex commented Jan 12, 2017 •

edited

Loading

mscdex commented Jan 12, 2017 •

edited

Loading

lance commented Jan 25, 2017 •

edited

Loading

targos commented Jan 25, 2017 •

edited

Loading

Krinkle Feb 1, 2017 •

edited

Loading