Re: cookies work for some browsers, not for others... ?
will trillich([EMAIL PROTECTED])@Sat, Apr 28, 2001 at 02:44:29PM -0500: i've been tinkering with the modperl book examples for Apache::Ticket*.pm (as described p305-322)... it works for linux/konqueror linux/netscape win/explorer it doesn't work for linux/lynx mac/netscape Dude you forgot excellent links browser - text mode and support for tables frames! pavel
Re: cookies work for some browsers, not for others... ?
- Original Message - From: will trillich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 9:44 PM Subject: cookies work for some browsers, not for others... ? [snip] cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? That's the formatting done for the chunked content-type. I really don't recall exactly how it works. All I remember is that each set of hexadecimal digits [that's what they are] somehow must represent the next chunk to be transferred - it might be a byte count. In any case, if you're REALLY interested, go look it up in the RFC for HTTP/1.1 - it's explained in better detail there. [snip] HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? See above. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: cookies work for some browsers, not for others... ?
- Original Message - From: will trillich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 9:44 PM Subject: cookies work for some browsers, not for others... ? [snip] cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? That's the formatting done for the chunked content-type. I really don't recall exactly how it works. All I remember is that each set of hexadecimal digits [that's what they are] somehow must represent the next chunk to be transferred - it might be a byte count. In any case, if you're REALLY interested, go look it up in the RFC for HTTP/1.1 - it's explained in better detail there. [snip] HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? See above. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
cookies work for some browsers, not for others... ?
i've been tinkering with the modperl book examples for Apache::Ticket*.pm (as described p305-322)... it works for linux/konqueror linux/netscape win/explorer it doesn't work for linux/lynx mac/netscape the ones that do work get to the login page with two textfields (username and password) with a login button; those that don't work get a your browser doesn't accept cookies page. where can i find some pointers on the differences between various browsers' adherence to standards, and hints on workarounds? (or, is this something else i've stumbled into?) -- here's a telnet trace of the situation, so apparently the program logic is working in all instances; but some browsers just won't play nice-- $ telnet sample-from-modperl-book.com 80 Trying ##.##.##.##... Connected to sample-from-modperl-book.com. Escape character is '^]'. GET /try HTTP/1.1 Host: sample-from-modperl-book.com HTTP/1.1 302 Found Date: Sat, 28 Apr 2001 19:26:48 GMT Server: Apache/1.3.9 Set-Cookie: request_uri=http%3A%2F%2Fsample-from-modperl-book.com%2Ftry%3F; domain=.sample-from-modperl-book.com; path=/ Location: http://www.sample-from-modperl-book.com/login Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? will@duo: /var/www/ed $ telnet sample-from-modperl-book.com 80 Trying ##.##.##.##... Connected to sample-from-modperl-book.com. Escape character is '^]'. GET /login HTTP/1.1 Host: sample-from-modperl-book.com Cookie: request_uri=http%3A%2F%2Fsample-from-modperl-book.com%2Ftry%3F; domain=.sample-from-modperl-book.com; path=/ HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: cookies work for some browsers, not for others... ?
in general, your problem with some browsers that otherwise support cookies may be with issuing redirects and cookies on the same request, which has been known to trip up some browsers. the easy workaround is to use a meta refresh to do the redirection. fmt: w70: No such file or directory On Sat, Apr 28, 2001 at 02:44:29PM -0500, will trillich wrote: ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? chunked encoding. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 jim
Re: cookies work for some browsers, not for others... ?
On Sat, Apr 28, 2001 at 12:54:17PM -0700, Jim Winstead wrote: in general, your problem with some browsers that otherwise support cookies may be with issuing redirects and cookies on the same request, which has been known to trip up some browsers. the easy workaround is to use a meta refresh to do the redirection. pooh. i'll look into that. hmm. they all do the redirect properly, but when they arrive at the redirected url, they don't seem to have (or at least report) the cookies they've been given. so i guess what you're saying is, some browsers look for a redirect: header and then charge off to the new location without handling any set-cookie: headers in the meantime? fmt: w70: No such file or directory hmm? -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: cookies work for some browsers, not for others... ?
At 17:17 28/04/2001 -0500, will trillich wrote: so i guess what you're saying is, some browsers look for a redirect: header and then charge off to the new location without handling any set-cookie: headers in the meantime? Precisely. And some also don't report the cookie before the second page after the redirect (presumably because they consider it to be the same request). I think that behaviour only happens with permanent redirects though. One thing that helps (often, not always) is to make sure that your Set-Cookie header is sent before the Location header of the redirect. ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Many people would sooner die than think. In fact, they do. - Bertrand Russell
Re: cookies work for some browsers, not for others... ?
On Sun, Apr 29, 2001 at 12:21:33AM +0200, Robin Berjon wrote:
At 17:17 28/04/2001 -0500, will trillich wrote:
so i guess what you're saying is, some browsers look for
a redirect: header and then charge off to the new location
without handling any set-cookie: headers in the meantime?
Precisely. And some also don't report the cookie before the second page
after the redirect (presumably because they consider it to be the same
request). I think that behaviour only happens with permanent redirects though.
One thing that helps (often, not always) is to make sure that your
Set-Cookie header is sent before the Location header of the redirect.
here's the code, direct from the modperl book, and downloaded in
person from modperl.com:
package Apache::TicketAccess;
use strict;
use Apache::Constants qw(:common);
use Apache::TicketTool ();
sub handler {
my $r = shift;
my $ticketTool = Apache::TicketTool-new($r);
my($result, $msg) = $ticketTool-verify_ticket($r);
unless ($result) {
$r-log_reason($msg, $r-filename);
my $cookie = $ticketTool-make_return_address($r);
$r-err_headers_out-add('Set-Cookie' = $cookie);
return FORBIDDEN;
}
return OK;
}
1;
__END__
i suppose i'd need to change
return FORBIDDEN;
to
print htmlheaders-including-meta-refresh, brief-html-stuff;
return OK;
right?
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
