Internet/Web classes in .NET/VC++...

  • Thread starter Thread starter Peter Hayes
  • Start date Start date
P

Peter Hayes

Hi All,

I have done some C, C++, C# development over the years, but wouldn't
call myself an 'expert' at any of them (this has always been a
part-time, write what is needed endeavor with whatever language was
available or necessary). My networking experience (in programming
anyway) is even more limited, although I have a basic understanding of
networks, TCP/IP, ethernet, etc.

I have a project that involves sending a query to a database with a
web-based interface. The response is a window that contains a javascript
function/method and some parameters (as well as a session cookie) that
open a child window and request the result of the query from another
page (with the cookie and some of the parameters specifying the specific
result requested).

If I use the C++ WebClient class, I can successfully get the end
results. I send the query parameters as name-value pairs, parse the
returned HTML and javascript to obtain the parameters necessary,
redirect the same WebClient object to the new page for the results, and
obtain the results.

The problem I have is that, in order to implement all the possible
queries, I cannot use the name-value form for sending data. The Web
interface to the database is not .NET, SOAP, or any 'standard'
interface, and uses formatting that the WebClient class doesn't like -
it reformats the queries so that the database end chokes on the more
complicated queries.

So, I tried the HTTPWebRequest class (inherited from WebRequest,
specific to HTTP). I can send all queries necessary and receive and
parse the initial response (the javascript and scripted redirect).
However, there seems to be no way to 'redirect' the HTTPWebRequest
object to a new page to retrieve the results.

Creating a new object using HTTPWebRequest has not, so far, worked (even
if I save and assign it the cookiecollection from the first request and
send the same sessionID cookie). Using an Ethernet sniffer I have
inspected the packets of the operating-but-limited WebCLient and the
non-operating-but-unlimited HTTPWebRequest and found a header entry of
"Path=/" as the only significant (that I can see) difference between the
one that works (and retrieves my results) and the one that does not (and
places me on a login page on the remote server - with no means of
logging in without starting over with a new sessionID). I have not found
any means of 'placing' the "Path=/" into the header - everything results
in an error because of the format.

Anyone have any ideas? I'm at a loss...

Thanks a lot for any suggestion! I'm wringing my hair on this one...



Pete
 
Peter Hayes said:
Hi All,

I have done some C, C++, C# development over the years, but wouldn't call
myself an 'expert' at any of them (this has always been a part-time, write
what is needed endeavor with whatever language was available or
necessary). My networking experience (in programming anyway) is even more
limited, although I have a basic understanding of networks, TCP/IP,
ethernet, etc.

I have a project that involves sending a query to a database with a
web-based interface. The response is a window that contains a javascript
function/method and some parameters (as well as a session cookie) that
open a child window and request the result of the query from another page
(with the cookie and some of the parameters specifying the specific result
requested).

If I use the C++ WebClient class, I can successfully get the end results.
I send the query parameters as name-value pairs, parse the returned HTML
and javascript to obtain the parameters necessary, redirect the same
WebClient object to the new page for the results, and obtain the results.

The problem I have is that, in order to implement all the possible
queries, I cannot use the name-value form for sending data. The Web
interface to the database is not .NET, SOAP, or any 'standard' interface,
and uses formatting that the WebClient class doesn't like - it reformats
the queries so that the database end chokes on the more complicated
queries.

So, I tried the HTTPWebRequest class (inherited from WebRequest, specific
to HTTP). I can send all queries necessary and receive and parse the
initial response (the javascript and scripted redirect). However, there
seems to be no way to 'redirect' the HTTPWebRequest object to a new page
to retrieve the results.

Creating a new object using HTTPWebRequest has not, so far, worked (even
if I save and assign it the cookiecollection from the first request and
send the same sessionID cookie). Using an Ethernet sniffer I have
inspected the packets of the operating-but-limited WebCLient and the
non-operating-but-unlimited HTTPWebRequest and found a header entry of
"Path=/" as the only significant (that I can see) difference between the
one that works (and retrieves my results) and the one that does not (and
places me on a login page on the remote server - with no means of logging
in without starting over with a new sessionID). I have not found any means
of 'placing' the "Path=/" into the header - everything results in an error
because of the format.

Anyone have any ideas? I'm at a loss...

Thanks a lot for any suggestion! I'm wringing my hair on this one...



Pete
Click to expand...

Have you tried to add a header to the HttpWebRequest::Headers collection of
your request?

Marcus
 
Hi Marcus,

Yes... tried to do that but cannot get the 'Path=/' into the header in
any way that I've been able to figure out... it errors out with (I
think) the '=' as not allowed. But that darn thing seems to be the only
difference between working and nonworking!
 
Just some additional fodder for the canon...

I recently found (how did I miss this initially, you ask? so do I...)
that the 'Path=/' is part of the SessionID cookie that the server sends
back with the result page after the successful query. The path is part
of the cookie. The difference is that the WebClient class returns the
path with the cookie while the HTTPWebRequest class does not return the
path with the cookie.

I don't believe that returningg the path is required (not in any cookie
documents I found anyway) but that is a difference between the two
packets...
 
Back
Top