Skip to content
This repository has been archived by the owner on Apr 21, 2020. It is now read-only.

Support requests with non-'utf-8' charsets #16

Merged
merged 51 commits into from
Oct 7, 2015

Conversation

theopak
Copy link
Collaborator

@theopak theopak commented Sep 24, 2015

Not ready to merge. EDIT: Ready, pending approval. UPDATE: Ready.

TODO

  • "fix the silent failures in the Travis-CI build"
  • skip body_parser middleware in case of empty body
  • add pre-mutator to stash original content type
  • add pre-mutator to convert content to UTF-8 so that body_parser.urlencoded() parses it
    • wontfix
  • add post-mutator to restore original content type
  • verify that non-utf-8 charsets are no longer silently failed
  • verify that, if removed, non-utf-8 charsets are always restored after body_parser.urlencoded() does its thing.
  • verify that requests with utf-8 query strings (e.g., emoji) are proxied correctly
    • unit tests exist and pass

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) {
Copy link
Collaborator Author

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?

Copy link
Contributor

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.

@theopak theopak mentioned this pull request Sep 28, 2015
@theopak
Copy link
Collaborator Author

theopak commented Sep 28, 2015

It took me waaaay too long to figure this out, but request.js (since v2.64.1) automatically overrides form requests to have Content-Type: "application/x-www-form-urlencoded" when they are sent to the server.

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.

@theopak
Copy link
Collaborator Author

theopak commented Sep 29, 2015

@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.

@theopak theopak changed the title Support requests with non--utf-8 charsets Support requests with non-'utf-8' charsets Sep 29, 2015
@@ -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');
Copy link
Collaborator Author

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).

@theopak
Copy link
Collaborator Author

theopak commented Oct 1, 2015

Inspecting req.argument_pairs during the unit tests, I notice that all the Java client's nonces are integers, and some of those are negative integers. This seems unusual to me. Two example values from failed requests:

[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?

@ryanbreen
Copy link
Contributor

I wouldn't think that would cause an issue. An integer is still a random string.

…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.
@theopak
Copy link
Collaborator Author

theopak commented Oct 5, 2015

@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

@@ -21,7 +21,7 @@ describe('oauth_proxy outbound message integrity: verbs', function() {
['GET', 'DELETE'].forEach(function(verb) {
Copy link
Collaborator Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

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.

@ryanbreen
Copy link
Contributor

LGTM!

ryanbreen added a commit that referenced this pull request Oct 7, 2015
Support requests with non-'utf-8' charsets
@ryanbreen ryanbreen merged commit c9e7358 into Cimpress-MCP:master Oct 7, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants