status-code 404 on our iriscouch when we contact it using nano, but not when using curl or a browser

[cesine]

We are getting a status-code 404 on our iriscouch when we contact it using nano in node.js at url like this:
https://adminuser:paswrod@xxxxx.iriscouch.com:443/_users/_design/users/_view/aview

It seems to redirect/work fine using curl or a browser. Everything else has been going great (~3 mos live), I suspect it's something with the nano library but its hard to contribute a solution since I'm not sure what iriscouch is doing to get us to our instance. I'd love any suggestions or if anyone has experienced something similar...

Here is the full error we are getting:

{ [Error: couch returned 404]
  name: 'Error',
  scope: 'couch',
  status_code: 404,
  'status-code': 404,
  request: 
   { method: 'GET',
     headers: 
      { 'content-type': 'application/json',
        accept: 'application/json' },
     uri: 'https://adminuser:paswrod@xxxxx.iriscouch.com:443/_users/_design/users/_view/aview',
     jar: false,
     callback: [Function] },
  headers: 
   { 'status-code': 404,
     uri: 'https://adminuser:paswrod@xxxxx.iriscouch.com:443/_users/_design/users/_view/aview' },
  errid: 'non_200',
  description: 'Host not found',
  stacktrace: 
   [ 'Error: Host not found',
     '    at Request._callback (.../node_modules/nano/nano.js:298:39)',
     '    at Request.init.self.callback (.../node_modules/nano/node_modules/request/main.js:120:22)',
     '    at Request.EventEmitter.emit (events.js:91:17)',
     '    at Request.<anonymous> (.../node_modules/nano/node_modules/request/main.js:555:16)',
     '    at Request.EventEmitter.emit (events.js:88:17)',
     '    at IncomingMessage.Request.start.self.req.self.httpModule.request.buffer (.../node_modules/nano/node_modules/request/main.js:517:14)',
     '    at IncomingMessage.EventEmitter.emit (events.js:115:20)',
     '    at IncomingMessage._emitEnd (http.js:366:10)',
     '    at HTTPParser.parserOnMessageComplete [as onMessageComplete] (http.js:149:23)' ] }

[dscape]

CouchDB doesn't listen on port 443. It's 5984 or 6984 (HTTPS).

Maybe this is the problem?

[dscape]

Can you send me a reproducible test case please? (like 20 lines of code showing your problem)

+@iriscouch

[dscape]

Closing this issue. Please reopen when you have the time to answer to my questions

[jhs]

This was Iris Couch downtime, sorry.

[dscape]

[cesine]

@dscape sorry about the delay.

CouchDB doesn't listen on port 443. It's 5984 or 6984 (HTTPS).

• True, couch listens on 5984, and/or 6984 if its https.
• We were using https on iriscouch, which is (proxying or something) via port 443

Today I will work on sending you a tiny node app containing the code necessary to reproduce the error so you can pick into it. It's not due to iriscouch being down... we still get the error.

[dscape]

@cesine please make a concise test case, using express is surely not concise. You can't expect me to go and look at hundreds of lines of code for something that should look like:

var nano = require('nano');
var users = nano("http://some.irisicouch.com/myusersdb");

users.view('users', 'aview', function (err, body) {
  // some code
});

[cesine]

I don't know how to use multiple nano instances with password protection in your test suite, pathetic eh? I cut the fluff. It's now at 68 lines, if you want only the case that fails, here it is:

var db = nano("https://admin:none@cesine.iriscouch.com:443/teststatus404error");
db.view("users", "usermasks", function(error, body) {
  console.log("It should connect to pass protected iriscouch via 443 ");
  if (error) {
    console.log("Fail");
  } else {
    console.log("Pass");
  }
});

The rest of the test cases are to show that this might not be desired behaviour:
https://github.com/cesine/nano/blob/cesine_branch/samples/accessing_view_error.js

[jhs]

Some extra information. (Charles Proxy FTW.)

For a URL of the format https://:443, both curl and the browsers
set the Host header to "something".

Nano sets it to "something:443"

So you can work around this by removing the ":443" (the "https" will still
give you SSL access).

However on the Iris Couch side I feel like we could fix this too. But first
I will check if there is any standard about this, maybe it really is a nano
(or request) bug.

On Sat, Nov 10, 2012 at 4:33 AM, cesine notifications@github.com wrote:

I don't know how to use multiple nano instances with password protection
in your test suite, pathetic eh? I cut the fluff. It's now at 75 lines, if
you want only the case that fails, here it is:

nano = require('nano')("https://admin:none@cesine.iriscouch.com:443");var db = nano.db.use("teststatus404error");db.view("users", "usermasks", function(error, body) {
console.log("It should connect to pass protected iriscouch via 443 ");
if (error) {
console.log("Fail");
} else {
console.log("Pass");
}});

The rest of the test cases are to show that this might not be desired
behaviour:

https://github.com/cesine/nano/blob/cesine_branch/samples/accessing_view_error.js

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/109#issuecomment-10245407.

Iris Couch

[cesine]

@jhs Have I mentioned that you are awesome! Thanks for digging. We are trying to keep all our couch connections paralel hence the port in all our configs. I was just going to switch our iris couches to 6984 but I think the right solution is to is to work around the Host header by going through our code and make sure we can use empty string ports as you suggested. We were originally doing that with our iris couches but for some reason we switched to specifying the ports...

@dscape In an unrelated side note, we are now connecting to couches that are running out of directories too eg https://localhost/adirectory/:6984 which is pretty abnormal, but the server admin insists on running everything through apache (I know...) so he can use his existing DOS monitors, and virtual hosts weren't an option. These new couches aren't in production yet, but if we get hiccups I'll see if I can start contributing to nano by tests and a patch for this issue since our project is fast becoming an edge case, we'll probably need to contrib at some point. This issue seems small enough that its a good place to start learning the codebase.

I'd say I'll know more in about a week or two... until then the workaround will work just fine for our case.

[dscape]

Sounds like a solid plan @cesine . I think you will soon find that all of this is mostly handled by @mikeal request library and not nano itself :)

[cesine]

2 weeks have passed... we are sticking with not specifying a port on iriscouch. no time to dig in deeper to the request library or nano since its not really necessary for this minor issue.

[dscape]

@cesine if you do find the time feel free to reopen with a pull request and tests. It might also be a request bug (@mikeal) so I'm updating nano to the lastest request and doing a version bump just in case.

[dscape]

New request landed in ff99077