-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: Cookie not in this host's domain. #794
Comments
@stash thoughts? |
A cookie with |
@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. |
@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. |
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. |
Note: the
I'll whip up a pr for this. |
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 |
argh i mean "request itself should not fail" |
@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! :) |
@lalitkapoor Fascinating! It seems OK. Great work! |
what would be the default domain if domain wasn't specified in the response cookie string
|
Refer this: request/request#794 This is an error from tough cookie and they allow us to ignore errors. Sometimes we don't wanna stop the request when there is an error in cookie setting. So, now we can allow user to ignore or raise error in setCookie. This will be helpful as most of use this package to fetch body from a request and we don't want to end up with an error when there is something wrong in setCookie.
Refer this: request/request#794 This is an error from tough cookie and they allow us to ignore errors. Sometimes we don't wanna stop the request when there is an error in cookie setting. So, now we can allow user to ignore or raise error in setCookie. This will be helpful as most of use this package to fetch body from a request and we don't want to end up with an error when there is something wrong in setCookie.
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 likeSet-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.The text was updated successfully, but these errors were encountered: