Wininet and Cookies
Keywords: Cookies
Question:
How does the WinInet Extender deal with cookies? I am trying to automate
data downloads from a website that requires several layers of user
interaction. It appears that the servers are using a cookie to hold some
information when accessed via a web browser.
If I run a script that does an iBegin, iHostConnect, iHostInit, and iHostOpen
sequence (standard stuff) I am able to talk to the web server and retrieve
the next page properly. The script then uses several different URLOpen
commands, using the same iBegin handle, to progress through a series of
other pages, including an HTTPS url. It seems like the cookie information is
somehow emulated correctly as long as the connection is not broken.
However, the script eventually needs to use a different iHostConnect
statement in order to connect to a secure server and POST a form. At that
point the cookie information seems to be gone and I get a "HTTP 1.1 302
found" error from the server.
I think that this is because of the new iHostConnect that was required to
post the form.
The script is somewhat long and complicated so I am looking for some
general information and guidelines without resorting to sending the entire
script.
Answer:
The WinInet extender uses the Internet Explorer cookie handling
mechanism.
It is enabled by default. It should work
100% the same as MSIE does.
It is possible to use the headers to send your own cookies.
Basically a cookie is just some header information that is automagically
attached to all your outgoing requests and remembered on the incoming
requests.
More Questions:
Thanks, that clears up how the cookie part could have been working. How
about the 302 found response? My understanding is that the new Url should
be returned in the "Location:" header. However I do not see this as one of
the response headers shown with the iHttpHeaders command that I use
following the iHttpOpen command. How do I obtain the value of response
headers (such as "Location:") from within my script?
Answer:
Well if iHttpHeaders does not see it, then it is inacessable.
I have a vague idea that was handled automagically though, so if you see a
302 error there is a real problem. I'm not 100% sure on that though.
Article ID: W14442
Filename: Wininet and Cookies.txt
File Created: 2000:09:27:15:04:22
Last Updated: 2000:09:27:15:04:22