-
Notifications
You must be signed in to change notification settings - Fork 5
Support requests with non-'utf-8' charsets #16
Conversation
it ("should support " + verb + " requests with non-'utf-8' charsets declared in the header", function(done) { | ||
var intended_content_type_header = 'text/html; charset=ISO-8859-8'; | ||
var custom_headers = { headers: {'Content-Type': intended_content_type_header } }; | ||
request_sender.sendRequest(verb, 'http://localhost:8080/livecheck', custom_headers, 200, function(err, res, body) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanbreen What job_server endpoint would be appropriate to test against in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think POST /job would be good. You want to make sure that a url-encoded post gets processed correctly.
…dash" on the Travis-CI build).
…ests in particular.
It took me waaaay too long to figure this out, but request.js (since v2.64.1) automatically overrides form requests to have request.js will not send the kind of requests that this PR is looking to test. Therefore I'll have to take a different approach in forming the test. |
…ch is used to form test requests
@ryanbreen Could you take a look at the test case and make sure that it adequately captures the exact issue you told me about? My progress is stalled on this PR because I'm having trouble replicating the exact issue that you described to me in the chat last Wednesday. |
-utf-8
charsets@@ -1,10 +1,6 @@ | |||
var _ = require('underscore'); | |||
var fs = require('fs'); | |||
var path = require('path'); | |||
|
|||
var request_sender = require('./utils/request_sender.js'); | |||
var validation_tools = require('./utils/validation_tools.js'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed because these are repeated in lines 8 and 9 (of the new file).
Inspecting [2015-10-01T20:09:48.988Z] TRACE: oauth_reverse_proxy/54621 on lexmac1909.vistaprint.net: (service_name=jobsservice, module=lib/proxy/validators/oauth_signature_validator.js)
req.argument_pairs:
[ [ 'oauth_consumer_key', 'java-test-key' ],
[ 'oauth_nonce', '1244941739633823073' ],
[ 'oauth_signature_method', 'HMAC-SHA1' ],
[ 'oauth_timestamp', '1443730188' ],
[ 'oauth_version', '1.0' ],
[ 'this', 'is' ],
[ 'fun', 'right' ] ]
[2015-10-01T20:12:37.531Z] TRACE: oauth_reverse_proxy/54666 on lexmac1909.vistaprint.net: (service_name=jobsservice, module=lib/proxy/validators/oauth_signature_validator.js)
req.argument_pairs:
[ [ 'oauth_consumer_key', 'java-test-key' ],
[ 'oauth_nonce', '-4825279163585566192' ],
[ 'oauth_signature_method', 'HMAC-SHA1' ],
[ 'oauth_timestamp', '1443730357' ],
[ 'oauth_version', '1.0' ],
[ 'this', 'is' ],
[ 'fun', 'right' ] ] "A nonce is a random string," according to http://oauth.net/core/1.0a/#nonce, which means that the other clients are following spec when they generate alphanumeric nonces as base64 encoded UTF-8 data. @rb Do you think this indicate a problem with the way that the client's requests are received? |
I wouldn't think that would cause an issue. An integer is still a random string. |
…ser.urlencoded() to throw an error due to unsupported charset.
…ins: /home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi /home/travis/perl5/lib/perl5 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at client.pl line 5.
… future. Not spending any more time on this.
…d never restored.
@ryanbreen The client library tests pass, with your changes, as of 7675b31 However, your changes have a typo: theopak#4 (comment) The tests fail if I fix the typo |
…ress-MCPGH-15 * commit '5a6f3af47e6c46a10641af9c505ec5eb904bb858': Also munge charsets on the jobserver test side.
@@ -21,7 +21,7 @@ describe('oauth_proxy outbound message integrity: verbs', function() { | |||
['GET', 'DELETE'].forEach(function(verb) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latter 4 test templates are the ones that still fail in the build, even though they pass on master.
$ set OAUTH_REVERSE_PROXY_LOG_LEVEL="trace"; mocha --reporter spec -t 10000 ./test/oauth_proxy_outbound_test.js | bunyan
64 passing (494ms)
8 failing
@ryanbreen any idea why? I've tried rolling back my changes one by one locally, and looking through the diff in this PR, but I can't pinpoint the line(s) that cause these tests to fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the failures are here:
8) should accept a properly signed DELETE over IPv6 with query via https
Error: Protocol "https:" not supported. Expected "http:".
at new ClientRequest (_http_client.js:53:11)
at Object.exports.request (http.js:31:10)
at Object.exports.request (https.js:163:15)
at Array.stream (/Users/wrb/tmp/oauth_reverse_proxy/node_modules/http-proxy/lib/http-proxy/passes/web-incoming.js:108:74)
at ProxyServer.<anonymous> (/Users/wrb/tmp/oauth_reverse_proxy/node_modules/http-proxy/lib/http-proxy/index.js:80:21)
I'm not sure what might have changed between this version and master. Looks like an https request is being sent with http.js. Not sure why that would happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it might be a node > 0.11.0 discrepancy: SamDecrock/node-http-ntlm#21
You might need to check the node-http-proxy version and see if there's an upgrade to address this, assuming the issue is from that package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Builds now thanks to your fix. Evidently the failures weren't directly related to using node > 0.11.0, but actually a change that happened when I upgraded dependencies and combined query_parser.js and url_parser.js without noticing all of the resulting differences.
Make test less vulnerable to differences in output between versions.
Set the proper agent for outbound requests.
LGTM! |
Support requests with non-'utf-8' charsets
Not ready to merge.EDIT: Ready, pending approval.UPDATE: Ready.TODO
body_parser
middleware in case of empty bodyadd pre-mutator to convert content to UTF-8 so thatbody_parser.urlencoded()
parses itutf-8
charsets are no longer silently failedutf-8
charsets are always restored afterbody_parser.urlencoded()
does its thing.utf-8
query strings (e.g., emoji) are proxied correctly