Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 48895
Status: resolved
Priority: 0/
Queue: CGI

People
Owner: MARKSTOS [...] cpan.org
Requestors: mkanat [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Sending cookies and a redirect at the same time fails under mod_perl 2.
Under mod_perl 2, when calling $cgi->redirect, if you also send cookies at the same time, it sends a 200 OK instead of a 302 Found. It's possible that this only happens when we also send page content along with the 302 (though I haven't confirmed that myself). This comment describes the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=376044#c34 Here's some comments from the mod_perl maintainer: https://bugzilla.mozilla.org/show_bug.cgi?id=376044#c39 https://bugzilla.mozilla.org/show_bug.cgi?id=376044#c48 And my response: https://bugzilla.mozilla.org/show_bug.cgi?id=376044#c50
On Thu Aug 20 18:09:23 2009, MKANAT wrote: Show quoted text
> Under mod_perl 2, when calling $cgi->redirect, if you also send cookies > at the same time, it sends a 200 OK instead of a 302 Found. It's > possible that this only happens when we also send page content along > with the 302 (though I haven't confirmed that myself). > > This comment describes the problem: > > https://bugzilla.mozilla.org/show_bug.cgi?id=376044#c34
I think we addressed this in a recent release in a patch to the documentation, clarifying this point: "All names arguments recognized by header() are also recognized by redirect(). However, most HTTP headers, including those generated by -cookie and -target, are ignored by the browser." Microsoft admits their server doesn't even send the cookie in this case: http://support.microsoft.com/kb/176113 This article has a reference back to the HTTP spec in comment 4: http://www.persistall.com/archive/2008/01/25/cookies--redirects--nightmares.aspx The relevant bit is here: "The HTTP 1.0 standard per http://www.w3.org/Protocols/rfc2109/rfc2109 in section "4.3.5 Sending Cookies in Unverifiable Transactions" says that cookies should not be set from unverifiable transactions. It states specifically that "Unverifiable transactions typically arise when a user agent automatically requests inlined or embedded entities or when it resolves redirection (3xx) responses from an origin server." So, "Set-Cookie" is not to be acted upon by browsers / user agents for 3xx redirects. Nothing in HTTP 1.1 changes this part of HTTP." Therefore, my conclusion is that the bug here is in your application. CGI.pm is doing it's part now by clearing stating in the documentation that while you technically can combine cookies and redirection, you should not do it. Mark
On Thu Aug 20 21:02:57 2009, MARKSTOS wrote: Show quoted text
> "All names arguments recognized by header() are also recognized by > redirect(). However, most HTTP headers, including those generated by > -cookie and -target, are ignored by the browser."
Fair enough, but it works just fine under mod_cgi. It only fails under mod_perl. And the browsers that I'm using seem to accept the cookie. We could perhaps re-work the application, though. A little difficult, but possible.
On Thu Aug 20 21:17:25 2009, MKANAT wrote: Show quoted text
> On Thu Aug 20 21:02:57 2009, MARKSTOS wrote:
> > "All names arguments recognized by header() are also recognized by > > redirect(). However, most HTTP headers, including those generated by > > -cookie and -target, are ignored by the browser."
> > Fair enough, but it works just fine under mod_cgi. It only fails under > mod_perl. And the browsers that I'm using seem to accept the cookie. > > We could perhaps re-work the application, though. A little difficult, > but possible.
I would entertain a patch if there's a way that CGI.pm could improve sending cookies on redirects, even though it's not recommended. The only patch linked to from the bug report was just a hack to turn off the mod_perl flag, which does not seem like a good way to solve it. I'm not a mod_perl hacker, and won't be attempting a fix myself.
Considering no one has expressed in interest in this since 2009 or supplied a test for it, I'm marking it as resolved due to old age.