asp sessions

I am trying to determine why the following commands to WWW::Mechanize::Shell result as they do:

[trwww@waveright trwww]$ perl -MWWW::Mechanize::Shell -e 'shell'
>get https://www.setsivr.odjfs.state.oh.us/Login.asp
Retrieving https://www.setsivr.odjfs.state.oh.us/Login.asp(200)
https://www.setsivr.odjfs.state.oh.us/cookieerror.htm>

The server appears to check requests for an asp session cookie. If one is not set, the servers response includes a Set-Cookie header and a Location: header set to /cookiecheck.asp. If the request to cookiecheck.asp does not have the cookie in the header, the client is then redirected to cookieerror.htm. If /cookiecheck.asp finds the cookie, it appears to redirect the client to the initial request, whose URI mustve been stored in the session.

Why does WWW::Mechanize get directed to cookieerror.htm?

I've posted this question before with no responses. I have done some deeper digging, but still with no success. I am hoping someone would be willing to assist this time.

The above procedure works with all the popular graphical browsers I have used. Lynx does NOT produce desired results, landing on cookieerror.htm like WWW::Mechanize does.

I tried to establish a session with the server using IO::Socket::SSL using the example from the POD. You can see the code at the following URI:

http://waveright.homeip.net/~trwww/code/iosocketsslclient.tx t

The first attempt sends a single line request to /Login.asp. The code then extracts the cookie and makes a two line request to /cookiecheck.asp. The response to this request is to redirect to cookieerror.htm.

The second attempt uses the HTTP headers I scraped from the "Live HTTP Headers" module available with Mozilla. The requests appear to be successful, but the reads hang.

Please help with this possible bug which I am sure has turned away more than one user from libwww-perl.

Thank you,

Todd W.

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: asp sessions

On Thu, 30 Dec 2004, toddrw69@excite.com wrote:

>
> I am trying to determine why the following commands to WWW::Mechanize::Shell result as they do:
>
> [trwww@waveright trwww]$ perl -MWWW::Mechanize::Shell -e 'shell'
> >get https://www.setsivr.odjfs.state.oh.us/Login.asp
> Retrieving https://www.setsivr.odjfs.state.oh.us/Login.asp(200)
> https://www.setsivr.odjfs.state.oh.us/cookieerror.htm>
[...]

A guess: JavaScript setting a cookie?


John

Re: asp sessions

"John J Lee" wrote in message
news:Pine.WNT.4.58.0412311723150.1528@vernon...
> On Thu, 30 Dec 2004, toddrw69@excite.com wrote:
>
> >
> > I am trying to determine why the following commands to
WWW::Mechanize::Shell result as they do:
> >
> > [trwww@waveright trwww]$ perl -MWWW::Mechanize::Shell -e 'shell'
> > >get https://www.setsivr.odjfs.state.oh.us/Login.asp
> > Retrieving https://www.setsivr.odjfs.state.oh.us/Login.asp(200)
> > https://www.setsivr.odjfs.state.oh.us/cookieerror.htm>
> [...]
>
> A guess: JavaScript setting a cookie?
>

Ive probably spent over 6 hours on this. Javascript in the client is the
first thing I checked.

http://www.nntp.perl.org/group/perl.libwww/5989

Todd W.

Re: asp sessions

On Thu, 30 Dec 2004, toddrw69@excite.com wrote:
[...]
> Why does WWW::Mechanize get directed to cookieerror.htm?

Beats me too. I get the same problem with this site using Python's
urllib2 &c. I tried near-identical headers to Firefox, and got the error
page.

Another guess: Sounds odd, I know, but I wonder if IIS/ASP.NET is
insisting on a persistent connection? I haven't tested that theory, but I
do notice that neither Lynx, nor Python/urllib2, nor libwww-perl (IIRC on
the latter) use persistent connections, and all fail; Firefox does, and
succeeds.

[...]
> I tried to establish a session with the server using IO::Socket::SSL
> using the example from the POD. You can see the code at the following
> URI:
[...]

Dropping back to a low level is obviously the right plan of attack, but I
can't help with the Perl code...


John