Commit 6976748b authored by Jérémy Lal's avatar Jérémy Lal

Imported Upstream version 5.1.0~dfsg

parent 2703ed49
......@@ -87,6 +87,8 @@ rules:
# Custom rules in tools/eslint-rules
require-buffer: 2
new-with-error: [2, "Error", "RangeError", "TypeError", "SyntaxError", "ReferenceError"]
# Global scoped method and vars
globals:
......
......@@ -24,7 +24,7 @@ icu_config.gypi
# various stuff that VC++ produces/uses
Debug/
!node_modules/debug/
!deps/npm/node_modules/node-gyp/node_modules/path-array/node_modules/array-index/node_modules/debug
!deps/v8/src/debug/
Release/
!doc/blog/**
......
This diff is collapsed.
## Code of Conduct
This Code of Conduct is adapted from [Rust's wonderful
CoC](http://www.rust-lang.org/conduct.html).
* We are committed to providing a friendly, safe and welcoming
environment for all, regardless of gender, sexual orientation,
disability, ethnicity, religion, or similar personal characteristic.
* Please avoid using overtly sexual nicknames or other nicknames that
might detract from a friendly, safe and welcoming environment for
all.
* Please be kind and courteous. There's no need to be mean or rude.
* Respect that some individuals and cultures consider the casual use of
profanity offensive and off-putting.
* Respect that people have differences of opinion and that every
design or implementation choice carries a trade-off and numerous
costs. There is seldom a right answer.
* Please keep unstructured critique to a minimum. If you have solid
ideas you want to experiment with, make a fork and see how it works.
* We will exclude you from interaction if you insult, demean or harass
anyone. That is not welcome behavior. We interpret the term
"harassment" as including the definition in the [Citizen Code of
Conduct](http://citizencodeofconduct.org/); if you have any lack of
clarity about what might be included in that concept, please read
their definition. In particular, we don't tolerate behavior that
excludes people in socially marginalized groups.
* Private harassment is also unacceptable. No matter who you are, if
you feel you have been or are being harassed or made uncomfortable
by a community member, please contact one of the channel ops or any
of the TSC members immediately with a capture (log, photo, email) of
the harassment if possible. Whether you're a regular contributor or
a newcomer, we care about making this community a safe place for you
and we've got your back.
* Likewise any spamming, trolling, flaming, baiting or other
attention-stealing behavior is not welcome.
* Avoid the use of personal pronouns in code comments or
documentation. There is no need to address persons when explaining
code (e.g. "When the developer").
......@@ -240,14 +240,48 @@ You can find more information [in the full LTS plan](https://github.com/nodejs/l
#### How does LTS work?
Once a stable branch enters LTS, no new features may be added to that release. Changes are
limited to bug fixes, security updates, possible npm updates, documentation updates, and certain
performance improvements that can be demonstrated to not break existing applications.
Semver-minor changes are only permitted if required for bug fixes. Semver-major changes are only
permitted if required for critical security and bug fixes.
Once a stable branch moves into Maintenance mode, only **critical** bugs, **critical** security fixes,
and documentation updates will be permitted.
Once a stable branch enters LTS, changes in that branch are limited to bug
fixes, security updates, possible npm updates, documentation updates, and
certain performance improvements that can be demonstrated to not break existing
applications. Semver-minor changes are only permitted if required for bug fixes
and then only on a case-by-case basis with LTS WG and possibly Core Technical
Committee (CTC) review. Semver-major changes are permitted only if required for
security related fixes.
Once a stable branch moves into Maintenance mode, only **critical** bugs,
**critical** security fixes, and documentation updates will be permitted.
#### Landing semver-minor commits in LTS
The default policy is to not land semver-minor or higher commits in any LTS
branch. However, the LTS WG or CTC can evaluate any individual semver-minor
commit and decide whether a special exception ought to be made. It is
expected that such exceptions would be evaluated, in part, on the scope
and impact of the changes on the code, the risk to ecosystem stability
incurred by accepting the change, and the expected benefit that landing the
commit will have for the ecosystem.
Any collaborator who feels a semver-minor commit should be landed in an LTS
branch should attach the `lts-agenda` label to the pull request. The LTS WG
will discuss the issue and, if necessary, will escalate the issue up to the
CTC for further discussion.
#### How are LTS Branches Managed?
There are currently three LTS branches: `v4.x`, `v0.10`, and `v0.12`. Each
of these is paired with a "staging" branch: `v4.x-staging`, `v0.10-staging`,
and `v0.12-staging`.
As commits land in `master`, they are cherry-picked back to each staging
branch as appropriate. If the commit applies only to the LTS branch, the
PR must be opened against the *staging* branch. Commits are selectively
pulled from the staging branch into the LTS branch only when a release is
being prepared and may be pulled into the LTS branch in a different order
than they were landed in staging.
Any collaborator may land commits into a staging branch, but only the release
team should land commits into the LTS branch while preparing a new
LTS release.
#### How can I help?
......@@ -255,14 +289,32 @@ When you send your pull request, consider including information about
whether your change is breaking. If you think your patch can be backported,
please feel free to include that information in the PR thread.
#### Who is doing the backporting?
The current plan is for commits to cherry pick into a staging branch (e.g. v4.x-staging),
which can be done by anyone. The preference would be for the individual landing the commit
on master to backport to staging branches if it is appropriate.
Several LTS related issue and PR labels have been provided:
* `lts-watch-v4.x` - tells the LTS WG that the issue/PR needs to be considered
for landing in the `v4.x-staging` branch.
* `lts-watch-v0.10` - tells the LTS WG that the issue/PR needs to be considered
for landing in the `v0.10-staging` branch.
* `lts-watch-v0.12` - tells the LTS WG that the issue/PR needs to be considered
for landing in the `v0.12-staging` branch.
* `land-on-v4.x` - tells the release team that the commit should be landed
in a future v4.x release
* `land-on-v0.10` - tells the release team that the commit should be landed
in a future v0.10 release
* `land-on-v0.12` - tells the release team that the commit should be landed
in a future v0.12 release
Any collaborator can attach these labels to any PR/issue. As commits are
landed into the staging branches, the `lts-watch-` label will be removed.
Likewise, as commits are landed in a LTS release, the `land-on-` label will
be removed.
Collaborators are encouraged to help the LTS WG by attaching the appropriate
`lts-watch-` label to any PR that may impact an LTS release.
#### How is an LTS release cut?
When the LTS working group determines that a new LTS release is required, selected commits
will be picked from the staging branch to be included in the release. This process of making
a release will be a collaboration between the LTS working group and the Release team.
When the LTS working group determines that a new LTS release is required,
selected commits will be picked from the staging branch to be included in the
release. This process of making a release will be a collaboration between the
LTS working group and the Release team.
# Contributing to Node.js
## Code of Conduct
The Code of Conduct explains the *bare minimum* behavior
expectations the Node Foundation requires of its contributors.
[Please read it before participating.](./CODE_OF_CONDUCT.md)
## Issue Contributions
When opening new issues or commenting on existing issues on this repository
......@@ -45,21 +51,21 @@ and built upon.
The rules for the master branch are less strict; consult the
[stability index](./doc/api/documentation.markdown#stability-index) for details.
In a nutshell, modules are at varying levels of API stability. Bug fixes are
In a nutshell, modules are at varying levels of API stability. Bug fixes are
always welcome but API or behavioral changes to modules at stability level 3
(Locked) are off-limits.
#### Dependencies
Node.js has several bundled dependencies in the *deps/* and the *tools/*
directories that are not part of the project proper. Any changes to files
directories that are not part of the project proper. Any changes to files
in those directories or its subdirectories should be sent to their respective
projects. Do not send your patch to us, we cannot accept it.
projects. Do not send your patch to us, we cannot accept it.
In case of doubt, open an issue in the
[issue tracker](https://github.com/nodejs/node/issues/) or contact one of the
[project Collaborators](https://github.com/nodejs/node/#current-project-team-members).
([IRC](http://webchat.freenode.net/?channels=io.js) is often the best medium.) Especially do so if you plan to work on something big. Nothing is more
([IRC](http://webchat.freenode.net/?channels=io.js) is often the best medium.) Especially do so if you plan to work on something big. Nothing is more
frustrating than seeing your hard work go to waste because your vision
does not align with the project team.
......@@ -81,8 +87,8 @@ $ git config --global user.name "J. Random User"
$ git config --global user.email "j.random.user@example.com"
```
Writing good commit logs is important. A commit log should describe what
changed and why. Follow these guidelines when writing one:
Writing good commit logs is important. A commit log should describe what
changed and why. Follow these guidelines when writing one:
1. The first line should be 50 characters or less and contain a short
description of the change prefixed with the name of the changed
......@@ -124,15 +130,15 @@ $ git rebase upstream/master
### Step 5: Test
Bug fixes and features **should come with tests**. Add your tests in the
test/parallel/ directory. Look at other tests to see how they should be
Bug fixes and features **should come with tests**. Add your tests in the
test/parallel/ directory. Look at other tests to see how they should be
structured (license boilerplate, common includes, etc.).
```text
$ ./configure && make -j8 test
```
Make sure the linter is happy and that all tests pass. Please, do not submit
Make sure the linter is happy and that all tests pass. Please, do not submit
patches that fail either check.
If you are updating tests and just want to run a single test to check it, you
......@@ -160,9 +166,9 @@ $ git push origin my-feature-branch
Go to https://github.com/yourusername/node and select your feature branch.
Click the 'Pull Request' button and fill out the form.
Pull requests are usually reviewed within a few days. If there are comments
Pull requests are usually reviewed within a few days. If there are comments
to address, apply your changes in a separate commit and push that to your
feature branch. Post a comment in the pull request afterwards; GitHub does
feature branch. Post a comment in the pull request afterwards; GitHub does
not send out notifications when you add commits.
......@@ -181,41 +187,3 @@ By making a contribution to this project, I certify that:
different license), as indicated in the file; or
* (c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified it.
## Code of Conduct
This Code of Conduct is adapted from [Rust's wonderful
CoC](http://www.rust-lang.org/conduct.html).
* We are committed to providing a friendly, safe and welcoming
environment for all, regardless of gender, sexual orientation,
disability, ethnicity, religion, or similar personal characteristic.
* Please avoid using overtly sexual nicknames or other nicknames that
might detract from a friendly, safe and welcoming environment for
all.
* Please be kind and courteous. There's no need to be mean or rude.
* Respect that people have differences of opinion and that every
design or implementation choice carries a trade-off and numerous
costs. There is seldom a right answer.
* Please keep unstructured critique to a minimum. If you have solid
ideas you want to experiment with, make a fork and see how it works.
* We will exclude you from interaction if you insult, demean or harass
anyone. That is not welcome behavior. We interpret the term
"harassment" as including the definition in the [Citizen Code of
Conduct](http://citizencodeofconduct.org/); if you have any lack of
clarity about what might be included in that concept, please read
their definition. In particular, we don't tolerate behavior that
excludes people in socially marginalized groups.
* Private harassment is also unacceptable. No matter who you are, if
you feel you have been or are being harassed or made uncomfortable
by a community member, please contact one of the channel ops or any
of the TC members immediately with a capture (log, photo, email) of
the harassment if possible. Whether you're a regular contributor or
a newcomer, we care about making this community a safe place for you
and we've got your back.
* Likewise any spamming, trolling, flaming, baiting or other
attention-stealing behavior is not welcome.
* Avoid the use of personal pronouns in code comments or
documentation. There is no need to address persons when explaining
code (e.g. "When the developer")
Node.js
=====
=======
[![Gitter](https://badges.gitter.im/Join Chat.svg)](https://gitter.im/nodejs/node?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
This repository began as a GitHub fork of
[joyent/node](https://github.com/joyent/node).
Node.js contributions, releases, and contributorship are under an
[open governance model](./GOVERNANCE.md).
We intend to land, with increasing regularity, releases which are
compatible with the npm ecosystem that has been built to date for
Node.js.
The Node.js project is supported by the
[Node.js Foundation](https://nodejs.org/en/foundation/). Contributions,
policies and releases are managed under an
[open governance model](./GOVERNANCE.md). We are also bound by a
[Code of Conduct](./CODE_OF_CONDUCT.md).
If you need help using or installing Node.js, please use the
[nodejs/help](https://github.com/nodejs/help) issue tracker.
## Release Types
The Node.js project maintains multiple types of releases:
* **Stable**: Released from active development branches of this repository,
versioned by [SemVer](http://semver.org/) and signed by a member of the
[Release Team](#release-team).
Code for Stable releases is organized in this repository by major version
number, For example: [v4.x](https://github.com/nodejs/node/tree/v4.x).
The major version number of Stable releases will increment every 6 months
allowing for breaking changes to be introduced. This happens in April and
October every year. Stable release lines beginning in October each year have
a maximum support life of 8 months. Stable release lines beginning in April
each year will convert to LTS (see below) after 6 months and receive further
support for 30 months.
* **LTS**: Releases that receive Long-term Support, with a focus on stability
and security. Every second Stable release line (major version) will become an
LTS line and receive 18 months of _Active LTS_ support and a further 12
months of _Maintenance_. LTS release lines are given alphabetically
ordered codenames, begining with v4 Argon. LTS releases are less frequent
and will attempt to maintain consistent major and minor version numbers,
only incrementing patch version numbers. There are no breaking changes or
feature additions, except in some special circumstances. More information
can be found in the [LTS README](https://github.com/nodejs/LTS/).
* **Nightly**: Versions of code in this repository on the current Stable
branch, automatically built every 24-hours where changes exist. Use with
caution.
## Download
Binaries, installers, and source tarballs are available at
<https://nodejs.org>.
**Releases** are available at <https://nodejs.org/dist/>, listed under
their version string. The <https://nodejs.org/dist/latest/> symlink
will point to the latest release directory.
**Stable** and **LTS** releases are available at
<https://nodejs.org/download/release/>, listed under their version strings.
The [latest](https://nodejs.org/download/release/latest/) directory is an
alias for the latest Stable release. The latest LTS release from an LTS
line is available in the form: latest-lts-_codename_. For example:
<https://nodejs.org/download/release/latest-lts-argon>
**Nightly** builds are available at
<https://nodejs.org/download/nightly/>, listed under their version
......@@ -28,11 +58,12 @@ string which includes their date (in UTC time) and the commit SHA at
the HEAD of the release.
**API documentation** is available in each release and nightly
directory under _docs_. <https://nodejs.org/api/> points to the latest version.
directory under _docs_. <https://nodejs.org/api/> points to the API
documentation of the latest stable version.
### Verifying Binaries
Release and nightly download directories all contain a *SHASUM256.txt*
Stable, LTS and Nightly download directories all contain a *SHASUM256.txt*
file that lists the SHA checksums for each file available for
download. To check that a downloaded file matches the checksum, run
it through `sha256sum` with a command such as:
......@@ -44,9 +75,9 @@ $ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -
_(Where "node-vx.y.z.tar.gz" is the name of the file you have
downloaded)_
Additionally, releases (not nightlies) have GPG signed copies of
SHASUM256.txt files available as SHASUM256.txt.asc. You can use `gpg`
to verify that the file has not been tampered with.
Additionally, Stable and LTS releases (not Nightlies) have GPG signed
copies of SHASUM256.txt files available as SHASUM256.txt.asc. You can use
`gpg` to verify that the file has not been tampered with.
To verify a SHASUM256.txt.asc, you will first need to import all of
the GPG keys of individuals authorized to create releases. They are
......@@ -226,6 +257,9 @@ Windows:
$ pkg-config --modversion icu-i18n && ./configure --with-intl=system-icu
```
If you are cross compiling, your `pkg-config` must be able to supply a path
that works for both your host and target environments.
#### Build with a specific ICU:
You can find other ICU releases at
......@@ -295,7 +329,9 @@ Instructions:
Appendix A in the [security policy]
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf).
The only exception is that `./config no-asm` can be
used in place of `./config` )
used in place of `./config`, and the FIPSDIR environment variable
may be used to specify a non-standard install folder for the
validated module, as per User Guide sections 4.2.1, 4.2.2, and 4.2.3.
6. Get into Node.js checkout folder
7. `./configure --openssl-fips=/path/to/openssl-fips/installdir`
For example on ubuntu 12 the installation directory was
......@@ -305,6 +341,7 @@ Instructions:
## Resources for Newcomers
* [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
* [CONTRIBUTING.md](./CONTRIBUTING.md)
* [GOVERNANCE.md](./GOVERNANCE.md)
* IRC:
......@@ -367,12 +404,15 @@ information about the governance of the Node.js project, see
* [qard](https://github.com/qard) - **Stephen Belanger** &lt;admin@stephenbelanger.com&gt;
* [rlidwka](https://github.com/rlidwka) - **Alex Kocharin** &lt;alex@kocharin.ru&gt;
* [robertkowalski](https://github.com/robertkowalski) - **Robert Kowalski** &lt;rok@kowalski.gd&gt;
* [romankl](https://github.com/romankl) - **Roman Klauke** &lt;romaaan.git@gmail.com&gt;
* [saghul](https://github.com/saghul) - **Saúl Ibarra Corretgé** &lt;saghul@gmail.com&gt;
* [sam-github](https://github.com/sam-github) - **Sam Roberts** &lt;vieuxtech@gmail.com&gt;
* [seishun](https://github.com/seishun) - **Nikolai Vavilov** &lt;vvnicholas@gmail.com&gt;
* [silverwind](https://github.com/silverwind) - **Roman Reiss** &lt;me@silverwind.io&gt;
* [srl295](https://github.com/srl295) - **Steven R Loomis** &lt;srloomis@us.ibm.com&gt;
* [targos](https://github.com/targos) - **Michaël Zasso** &lt;mic.besace@gmail.com&gt;
* [tellnes](https://github.com/tellnes) - **Christian Tellnes** &lt;christian@tellnes.no&gt;
* [thealphanerd](http://github.com/thealphanerd) - **Myles Borins** &lt;myles.borins@gmail.com&gt;
* [thefourtheye](https://github.com/thefourtheye) - **Sakthipriyan Vairamani** &lt;thechargingvolcano@gmail.com&gt;
* [thlorenz](https://github.com/thlorenz) - **Thorsten Lorenz** &lt;thlorenz@gmx.de&gt;
* [Trott](https://github.com/Trott) - **Rich Trott** &lt;rtrott@gmail.com&gt;
......@@ -387,7 +427,7 @@ maintaining the Node.js project.
Releases of Node.js and io.js will be signed with one of the following GPG keys:
* **Chris Dickinson** &lt;christopher.s.dickinson@gmail.com&gt;: `9554F04D7259F04124DE6B476D5A82AC7E37093B`
* **Chris Dickinson** &lt;christopher.s.dickinson@gmail.com&gt; `9554F04D7259F04124DE6B476D5A82AC7E37093B`
* **Colin Ihrig** &lt;cjihrig@gmail.com&gt; `94AE36675C464D64BAFA68DD7434390BDBE9B9C5`
* **Sam Roberts** &lt;octetcloud@keybase.io&gt; `0034A06D9D9B0064CE8ADF6BF1747F4AD2306D93`
* **Jeremiah Senkpiel** &lt;fishrock@keybase.io&gt; `FD3A5288F042B6850C66B31F09FE44734EB7990E`
......
......@@ -110,40 +110,40 @@ Note that the i18n working groups are distinct from the [Intl](#Intl) working gr
Each language community maintains its own membership.
* [iojs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/iojs-ar)
* [iojs-bg - Bulgarian (български език)](https://github.com/nodejs/iojs-bg)
* [iojs-bn - Bengali (বাংলা)](https://github.com/nodejs/iojs-bn)
* [iojs-cn - Chinese (中文)](https://github.com/nodejs/iojs-cn)
* [iojs-cs - Czech (Český Jazyk)](https://github.com/nodejs/iojs-cs)
* [iojs-da - Danish (Dansk)](https://github.com/nodejs/iojs-da)
* [iojs-de - German (Deutsch)](https://github.com/nodejs/iojs-de)
* [iojs-el - Greek (Ελληνικά)](https://github.com/nodejs/iojs-el)
* [iojs-es - Spanish (Español)](https://github.com/nodejs/iojs-es)
* [iojs-fa - Persian (فارسی)](https://github.com/nodejs/iojs-fa)
* [iojs-fi - Finnish (Suomi)](https://github.com/nodejs/iojs-fi)
* [iojs-fr - French (Français)](https://github.com/nodejs/iojs-fr)
* [iojs-he - Hebrew (עברית)](https://github.com/nodejs/iojs-he)
* [iojs-hi - Hindi (फिजी बात)](https://github.com/nodejs/iojs-hi)
* [iojs-hu - Hungarian (Magyar)](https://github.com/nodejs/iojs-hu)
* [iojs-id - Indonesian (Bahasa Indonesia)](https://github.com/nodejs/iojs-id)
* [iojs-it - Italian (Italiano)](https://github.com/nodejs/iojs-it)
* [iojs-ja - Japanese (日本語)](https://github.com/nodejs/iojs-ja)
* [iojs-ka - Georgian (ქართული)](https://github.com/nodejs/iojs-ka)
* [iojs-ko - Korean (조선말)](https://github.com/nodejs/iojs-ko)
* [iojs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/iojs-mk)
* [iojs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/iojs-ms)
* [iojs-nl - Dutch (Nederlands)](https://github.com/nodejs/iojs-nl)
* [iojs-no - Norwegian (Norsk)](https://github.com/nodejs/iojs-no)
* [iojs-pl - Polish (Język Polski)](https://github.com/nodejs/iojs-pl)
* [iojs-pt - Portuguese (Português)](https://github.com/nodejs/iojs-pt)
* [iojs-ro - Romanian (Română)](https://github.com/nodejs/iojs-ro)
* [iojs-ru - Russian (Русский)](https://github.com/nodejs/iojs-ru)
* [iojs-sv - Swedish (Svenska)](https://github.com/nodejs/iojs-sv)
* [iojs-ta - Tamil (தமிழ்)](https://github.com/nodejs/iojs-ta)
* [iojs-tr - Turkish (Türkçe)](https://github.com/nodejs/iojs-tr)
* [iojs-tw - Taiwanese (Hō-ló)](https://github.com/nodejs/iojs-tw)
* [iojs-uk - Ukrainian (Українська)](https://github.com/nodejs/iojs-uk)
* [iojs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/iojs-vi)
* [nodejs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/nodejs-ar)
* [nodejs-bg - Bulgarian (български език)](https://github.com/nodejs/nodejs-bg)
* [nodejs-bn - Bengali (বাংলা)](https://github.com/nodejs/nodejs-bn)
* [nodejs-zh-CN - Chinese (中文)](https://github.com/nodejs/nodejs-zh-CN)
* [nodejs-cs - Czech (Český Jazyk)](https://github.com/nodejs/nodejs-cs)
* [nodejs-da - Danish (Dansk)](https://github.com/nodejs/nodejs-da)
* [nodejs-de - German (Deutsch)](https://github.com/nodejs/nodejs-de)
* [nodejs-el - Greek (Ελληνικά)](https://github.com/nodejs/nodejs-el)
* [nodejs-es - Spanish (Español)](https://github.com/nodejs/nodejs-es)
* [nodejs-fa - Persian (فارسی)](https://github.com/nodejs/nodejs-fa)
* [nodejs-fi - Finnish (Suomi)](https://github.com/nodejs/nodejs-fi)
* [nodejs-fr - French (Français)](https://github.com/nodejs/nodejs-fr)
* [nodejs-he - Hebrew (עברית)](https://github.com/nodejs/nodejs-he)
* [nodejs-hi - Hindi (फिजी बात)](https://github.com/nodejs/nodejs-hi)
* [nodejs-hu - Hungarian (Magyar)](https://github.com/nodejs/nodejs-hu)
* [nodejs-id - Indonesian (Bahasa Indonesia)](https://github.com/nodejs/nodejs-id)
* [nodejs-it - Italian (Italiano)](https://github.com/nodejs/nodejs-it)
* [nodejs-ja - Japanese (日本語)](https://github.com/nodejs/nodejs-ja)
* [nodejs-ka - Georgian (ქართული)](https://github.com/nodejs/nodejs-ka)
* [nodejs-ko - Korean (조선말)](https://github.com/nodejs/nodejs-ko)
* [nodejs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/nodejs-mk)
* [nodejs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/nodejs-ms)
* [nodejs-nl - Dutch (Nederlands)](https://github.com/nodejs/nodejs-nl)
* [nodejs-no - Norwegian (Norsk)](https://github.com/nodejs/nodejs-no)
* [nodejs-pl - Polish (Język Polski)](https://github.com/nodejs/nodejs-pl)
* [nodejs-pt - Portuguese (Português)](https://github.com/nodejs/nodejs-pt)
* [nodejs-ro - Romanian (Română)](https://github.com/nodejs/nodejs-ro)
* [nodejs-ru - Russian (Русский)](https://github.com/nodejs/nodejs-ru)
* [nodejs-sv - Swedish (Svenska)](https://github.com/nodejs/nodejs-sv)
* [nodejs-ta - Tamil (தமிழ்)](https://github.com/nodejs/nodejs-ta)
* [nodejs-tr - Turkish (Türkçe)](https://github.com/nodejs/nodejs-tr)
* [nodejs-zh-TW - Taiwanese (Hō-ló)](https://github.com/nodejs/nodejs-zh-TW)
* [nodejs-uk - Ukrainian (Українська)](https://github.com/nodejs/nodejs-uk)
* [nodejs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/nodejs-vi)
### [Intl](https://github.com/nodejs/Intl)
......
......@@ -183,7 +183,6 @@
'-fsanitize=address',
'-DLEAK_SANITIZER'
],
'cflags_cc+': [ '-gline-tables-only' ],
'cflags!': [ '-fomit-frame-pointer' ],
'ldflags': [ '-fsanitize=address' ],
}],
......
......@@ -753,11 +753,15 @@ def configure_library(lib, output):
if pkg_cflags:
output['include_dirs'] += (
filter(None, map(str.strip, pkg_cflags.split('-I'))))
elif options.__dict__[shared_lib + '_includes']:
output['include_dirs'] += [options.__dict__[shared_lib + '_includes']]
# libpath needs to be provided ahead libraries
if pkg_libpath:
output['libraries'] += (
filter(None, map(str.strip, pkg_cflags.split('-L'))))
output['libraries'] += [pkg_libpath]
elif options.__dict__[shared_lib + '_libpath']:
output['libraries'] += [
'-L%s' % options.__dict__[shared_lib + '_libpath']]
default_libs = getattr(options, shared_lib + '_libname')
default_libs = map('-l{0}'.format, default_libs.split(','))
......
......@@ -65,3 +65,4 @@ Romain Giraud <giraud.romain@gmail.com>
Jay Satiro <raysatiro@yahoo.com>
Arne Steen <Arne.Steen@gmx.de>
Kjell Schubert <kjell.schubert@gmail.com>
Olivier Mengué <dolmen@cpan.org>
......@@ -19,7 +19,19 @@
# IN THE SOFTWARE.
PLATFORM ?= $(shell sh -c 'uname -s | tr "[A-Z]" "[a-z]"')
SONAME ?= libhttp_parser.so.2.5.0
HELPER ?=
BINEXT ?=
ifeq (darwin,$(PLATFORM))
SONAME ?= libhttp_parser.2.6.0.dylib
SOEXT ?= dylib
else ifeq (wine,$(PLATFORM))
CC = winegcc
BINEXT = .exe.so
HELPER = wine
else
SONAME ?= libhttp_parser.so.2.6.0
SOEXT ?= so
endif
CC?=gcc
AR?=ar
......@@ -53,8 +65,8 @@ LDFLAGS_LIB += -Wl,-soname=$(SONAME)
endif
test: test_g test_fast
./test_g
./test_fast
$(HELPER) ./test_g$(BINEXT)
$(HELPER) ./test_fast$(BINEXT)
test_g: http_parser_g.o test_g.o
$(CC) $(CFLAGS_DEBUG) $(LDFLAGS) http_parser_g.o test_g.o -o $@
......@@ -81,7 +93,7 @@ http_parser.o: http_parser.c http_parser.h Makefile
$(CC) $(CPPFLAGS_FAST) $(CFLAGS_FAST) -c http_parser.c
test-run-timed: test_fast
while(true) do time ./test_fast > /dev/null; done
while(true) do time $(HELPER) ./test_fast$(BINEXT) > /dev/null; done
test-valgrind: test_g
valgrind ./test_g
......@@ -102,10 +114,10 @@ url_parser_g: http_parser_g.o contrib/url_parser.c
$(CC) $(CPPFLAGS_DEBUG) $(CFLAGS_DEBUG) $^ -o $@
parsertrace: http_parser.o contrib/parsertrace.c
$(CC) $(CPPFLAGS_FAST) $(CFLAGS_FAST) $^ -o parsertrace
$(CC) $(CPPFLAGS_FAST) $(CFLAGS_FAST) $^ -o parsertrace$(BINEXT)
parsertrace_g: http_parser_g.o contrib/parsertrace.c
$(CC) $(CPPFLAGS_DEBUG) $(CFLAGS_DEBUG) $^ -o parsertrace_g
$(CC) $(CPPFLAGS_DEBUG) $(CFLAGS_DEBUG) $^ -o parsertrace_g$(BINEXT)
tags: http_parser.c http_parser.h test.c
ctags $^
......@@ -113,12 +125,12 @@ tags: http_parser.c http_parser.h test.c
install: library
$(INSTALL) -D http_parser.h $(INCLUDEDIR)/http_parser.h
$(INSTALL) -D $(SONAME) $(LIBDIR)/$(SONAME)
ln -s $(LIBDIR)/$(SONAME) $(LIBDIR)/libhttp_parser.so
ln -s $(LIBDIR)/$(SONAME) $(LIBDIR)/libhttp_parser.$(SOEXT)
install-strip: library
$(INSTALL) -D http_parser.h $(INCLUDEDIR)/http_parser.h
$(INSTALL) -D -s $(SONAME) $(LIBDIR)/$(SONAME)
ln -s $(LIBDIR)/$(SONAME) $(LIBDIR)/libhttp_parser.so
ln -s $(LIBDIR)/$(SONAME) $(LIBDIR)/libhttp_parser.$(SOEXT)
uninstall:
rm $(INCLUDEDIR)/http_parser.h
......@@ -128,7 +140,8 @@ uninstall:
clean:
rm -f *.o *.a tags test test_fast test_g \
http_parser.tar libhttp_parser.so.* \
url_parser url_parser_g parsertrace parsertrace_g
url_parser url_parser_g parsertrace parsertrace_g \
*.exe *.exe.so
contrib/url_parser.c: http_parser.h
contrib/parsertrace.c: http_parser.h
......
......@@ -94,7 +94,7 @@ The Special Problem of Upgrade
------------------------------
HTTP supports upgrading the connection to a different protocol. An
increasingly common example of this is the Web Socket protocol which sends
increasingly common example of this is the WebSocket protocol which sends
a request like
GET /demo HTTP/1.1
......@@ -106,8 +106,8 @@ a request like
followed by non-HTTP data.
(See http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 for more
information the Web Socket protocol.)
(See [RFC6455](https://tools.ietf.org/html/rfc6455) for more information the
WebSocket protocol.)
To support this, the parser will treat this as a normal HTTP message without a
body, issuing both on_headers_complete and on_message_complete callbacks. However
......@@ -137,6 +137,69 @@ There are two types of callbacks:
Callbacks must return 0 on success. Returning a non-zero value indicates
error to the parser, making it exit immediately.
For cases where it is necessary to pass local information to/from a callback,
the `http_parser` object's `data` field can be used.
An example of such a case is when using threads to handle a socket connection,
parse a request, and then give a response over that socket. By instantiation
of a thread-local struct containing relevant data (e.g. accepted socket,
allocated memory for callbacks to write into, etc), a parser's callbacks are
able to communicate data between the scope of the thread and the scope of the
callback in a threadsafe manner. This allows http-parser to be used in
multi-threaded contexts.
Example:
```
typedef struct {
socket_t sock;
void* buffer;
int buf_len;
} custom_data_t;
int my_url_callback(http_parser* parser, const char *at, size_t length) {
/* access to thread local custom_data_t struct.