Error: Cookie not in this host's domain.

[breezewish]

Such kind of tough-cookie errors should be ignored, however currently they cause errors and break normal requesting.

For example, assume http://foo.bar.com returns headers like Set-Cookie: NAME=value; path=/; domain=hello.bar.com. It is an invalid cookie.
With the newest request module, this request will fail. I do not think this is a correct behaviour. These errors should be ignored.

[lalitkapoor]

@stash thoughts?

[stash]

A cookie with domain=hello.bar.com with host foo.bar.com will get rejected per the RFC (and in pretty much every browser too, I'm fairly confident). In order to set a cookie, the domain= parameter must be either the same domain or a sub-domain of the current page.

[breezewish]

@stash Yes, but the point is, in this case tough-cookie will throw an error so the callback function of the whole request will get that error instead of HTMLs. However this kind of cookie issues should be something like warnings, which do not cause failures. Browsers indeed ignore wrong cookies, but they won't give an error page to users.

[lalitkapoor]

@stash I agree with @breeswish on this. I don't think request should return an error here as a result of the server sending a bad cookie header.

We could let tough-cookie continue to throw an error because it's an invalid cookie and handle the error in this library (by ignoring it/not adding it to the jar). We could alternatively do somethings in tough-cookie, but I think I'd prefer the former.

[mikeal]

it makes sense to me that tough-cookie could throw, or return an error, on bad input and request could just handle that bad input.

if we have to do a try/catch remember that it has performance implications and opts out of any inlining inside the try/catch block.

[lalitkapoor]

Note: the setCookie method has an option to ignore errors like these:

ignoreError - boolean - default false - silently ignore things like parse errors and invalid domains. CookieStore errors aren't ignored by this option.

I'll whip up a pr for this.

[stash]

Apologies; i guess i misread the issue. Yes, I agree that the HTTP request itself should fail; it makes complete sense to ignore the cookie error (and just discard the set-cookie).

[stash]

argh i mean "request itself should not fail"

[lalitkapoor]

@breeswish I pushed an update to the master branch to address this. Can you tell me if you continue to experience this problem? (you'll have to pull it down - not npm install). I'd really appreciate it. Thanks! :)

[breezewish]

@lalitkapoor Fascinating! It seems OK. Great work!

[jtara1]

what would be the default domain if domain wasn't specified in the response cookie string

> jar.setCookie(req.cookie('abcaaa=aaa'))
Cookie="abcaaa=aaa; Path=/; hostOnly=true; aAge=0ms; cAge=0ms"
> jar.getCookieString()
''