Adding request.url for connect compatibility

[sebdeckers]

Having the request.url property aliased to request.path fixes a bug with the popular connect framework. Is this acceptable as backwards compatibility or would it be API bloat?

[mcollina]

Definitely, but would you mind adding a unit test?See https://github.com/nodejs/http2/blob/master/test/parallel/test-http2-create-client-session.js as an example of a client API.

[sebdeckers]

@mcollina I'd be happy to. Still figuring out how to efficiently develop on the Node codebase. Takes a while to recompile.

• Is there like a "watch mode" that monitors source code changes, recompiles, and re-runs tests more efficiently?
• Do I really need to recompile (make && make install) even if I only change the JS files?

[mcollina]

no there is not a "watch mode", but we usually just run a single unit test, so: make && ./node https://github.com/nodejs/http2/blob/master/test/parallel/test-http2-create-client-session.js in the example. If it does not throw, it passes.

You do not have to do make install.

It does not recompile all of it if you do not switch between branches.

[sebdeckers]

@mcollina@jasnell Would the test case in the second commit (967a0fb) be suitable? I just mean the way it's written; the test won't actually pass until to the request headers problem is resolved in #47.

[sebdeckers]

Closing this PR in favour of #47. I've added the same url -> path alias, with a test assertion, in 326fee5.