This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: nodejs/node-v0.x-archive
base: a7820a15e7eb
Could not load branches
Nothing to show
Could not load tags
Nothing to show
{{ refName }}
default
...
head repository: nodejs/node-v0.x-archive
compare: 0882a7506394
Could not load branches
Nothing to show
Could not load tags
Nothing to show
{{ refName }}
default
- 16 commits
- 213 files changed
- 2 contributors
Commits on Jun 3, 2013
-
In some cases, the http CONNECT/Upgrade API is unshifting an empty bodyHead buffer onto the socket. Normally, stream.unshift(chunk) does not set state.reading=false. However, this check was not being done for the case when the chunk was empty (either `''` or `Buffer(0)`), and as a result, it was causing the socket to think that a read had completed, and to stop providing data. This bug is not limited to http or web sockets, but rather would affect any parser that unshifts data back onto the source stream without being very careful to never unshift an empty chunk. Since the intent of unshift is to *not* change the state.reading property, this is a bug. Fixes #5557 Fixes socketio/socket.io#1242
-
url: Properly parse certain oddly formed urls
In cases where there are multiple @-chars in a url, Node currently parses the hostname and auth sections differently than web browsers. This part of the bug is serious, and should be landed in v0.10, and also ported to v0.8, and releases made as soon as possible. The less serious issue is that there are many other sorts of malformed urls which Node either accepts when it should reject, or interprets differently than web browsers. For example, `http://a.com*foo` is interpreted by Node like `http://a.com/*foo` when web browsers treat this as `http://a.com%3Bfoo/`. In general, *only* the `hostEndingChars` should be the characters that delimit the host portion of the URL. Most of the current `nonHostChars` that appear in the hostname should be escaped, but some of them (such as `;` and `%` when it does not introduce a hex pair) should raise an error. We need to have a broader discussion about whether it's best to throw in these cases, and potentially break extant programs, or return an object that has every field set to `null` so that any attempt to read the hostname/auth/etc. will appear to be empty.
-
Commits on Jun 4, 2013
-
-
-
-
-
-
-
-
2013.06.04, Version 0.10.10 (Stable)
* uv: Upgrade to 0.10.10 * npm: Upgrade to 1.2.25 * url: Properly parse certain oddly formed urls (isaacs) * stream: unshift('') is a noop (isaacs)
-
-
-
Commits on Jun 5, 2013
-
net: Destroy when not readable and not writable
This is only relevant for CentOS 6.3 using kernel version 2.6.32. On other linuxes and darwin, the `read` call gets an ECONNRESET in that case. On sunos, the `write` call fails with EPIPE. However, old CentOS will occasionally send an EOF instead of a ECONNRESET or EPIPE when the client has been destroyed abruptly. Make sure we don't keep trying to write or read more in that case. Fixes #5504 However, there is still the question of what libuv should do when it gets an EOF. Apparently in this case, it will continue trying to read, which is almost certainly the wrong thing to do. That should be fixed in libuv, even though this works around the issue.
-
Merge remote-tracking branch 'ry/v0.10'
Conflicts: ChangeLog deps/uv/AUTHORS deps/uv/ChangeLog deps/uv/src/unix/linux-core.c deps/uv/src/version.c deps/uv/src/win/timer.c lib/url.js src/node_version.h test/simple/test-url.js
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff a7820a15e7eb...0882a7506394