Threads
Well-known member
Hi,
Anyone out there familiar with the old WinInet routines for httpsendrequest and httpopenrequest and such? Although it wasnt as easy to work with as HttpWebRequest, it did have features that seem to be missing in HttpWebRequest. For example, the whole cookie thing... by default the WinInet libraries would get the current cookie for the domain you were requesting the page for from IE, and put it in the headers, that way sites that a user was logged into that I was interacting with, automatically found the login information. With the HttpWebRequest, that is completely lacking... now that said, I know it is possible to add a cookie manually to the header, but they dont even give a way to look up the default cookie that the current user has for it. I am stuck using the old InternetGetCookie WinInet function to do that. Plus, since it doesnt automatically get the cookie, it doesnt automatically update the users cookie if a change is made.
By default, all the cookie operations were happening in WinInet so that it would get the current cookie, and change the current cookie in the browser if a change was detected. This behavior could be turned off obviously, but it was very helpful.
It seems to me that with HttpWebRequest, there is not even a setting for this behavior to continue. Furthermore, it doesnt offer the functions necessary to get the current cookie (must revert back to using InternetGetCookie in WinInet). Am I wrong about this? Is there some hidden setting that I am not seeing that I can change to make it do what WinInet use to do?
I know it sounds like Im just complaining a lot, but one of the problems I have run into is that even when I set the cookie manually, then make a request, if the request is redirected (you can set the max number of redirects) it doesnt use the cookie I set for it to use when it is redirected, so it is like the user is not logged in again. The problem is that a lot of the pages have automatic redirects when you are submitting data to a form and such, so suddenly the response I get back doesnt even have the user logged in anymore.
Sorry for rambling If you made it this far you deserve some milk with those cookies.
Anyone out there familiar with the old WinInet routines for httpsendrequest and httpopenrequest and such? Although it wasnt as easy to work with as HttpWebRequest, it did have features that seem to be missing in HttpWebRequest. For example, the whole cookie thing... by default the WinInet libraries would get the current cookie for the domain you were requesting the page for from IE, and put it in the headers, that way sites that a user was logged into that I was interacting with, automatically found the login information. With the HttpWebRequest, that is completely lacking... now that said, I know it is possible to add a cookie manually to the header, but they dont even give a way to look up the default cookie that the current user has for it. I am stuck using the old InternetGetCookie WinInet function to do that. Plus, since it doesnt automatically get the cookie, it doesnt automatically update the users cookie if a change is made.
By default, all the cookie operations were happening in WinInet so that it would get the current cookie, and change the current cookie in the browser if a change was detected. This behavior could be turned off obviously, but it was very helpful.
It seems to me that with HttpWebRequest, there is not even a setting for this behavior to continue. Furthermore, it doesnt offer the functions necessary to get the current cookie (must revert back to using InternetGetCookie in WinInet). Am I wrong about this? Is there some hidden setting that I am not seeing that I can change to make it do what WinInet use to do?
I know it sounds like Im just complaining a lot, but one of the problems I have run into is that even when I set the cookie manually, then make a request, if the request is redirected (you can set the max number of redirects) it doesnt use the cookie I set for it to use when it is redirected, so it is like the user is not logged in again. The problem is that a lot of the pages have automatic redirects when you are submitting data to a form and such, so suddenly the response I get back doesnt even have the user logged in anymore.
Sorry for rambling If you made it this far you deserve some milk with those cookies.