MFC and secure HTTP: clarification of question
Jim McCabe -- jmccabe@mail.portup.com Tuesday, August 20, 1996 Environment: Win95, MSVC 4.2 I originally asked if it was possible to connect to https://... sites using the new MFC Internet classes. In my post I said that AfxParseURL doesn't recognize "https:" but does allow "shttp:". Then I went on to talk about how I wasn't able to connect to a site. There are some additional variables that might make a difference: a) Because of the AfxParseURL problem, I rephrased my URL using shttp, and it successfully passed AfxParseURL. b) When using Netscape, when I connect to the site I need to enter a userid and password. I was passing the correct strings to MFC and forgot to mention this. c) With the new URL (see (a)), I was able to successfully make it through the steps needed to access the page until CHttpFile::SendRequest(), which seems to cause the first real attempt to connect to the host. That is, I was able to establish a session, get an HTTP connection, and open the request just fine. d) I had previously moaned about the TEAR example, which didn't work. A couple people from the list responded and told me how to fix the problem, so I tried it and it works great. However, TEAR was also not able to connect to the https: site (of course using shttp: instead). This shouldn't be a surprise, but I thought I'd mention that it was tried. The original note follows. >I'm using the new MFC internet classes and have two questions: > >First, is it possible to connect to "https://..." sites? There seems to be >support for "secure http", but AfxParseURL doesn't recognize "https:". >However, it does recognize "shttp:". Trying to connect to: > > https://swww.etrade.com/cgi-bin/cgitrade/MainMenu > >... CHttpFile::SendRequest() returns error 12029 ("cannot connect"), even >though I'm passing INTERNET_FLAG_SECURE to CHttpConnection::OpenRequest(). >There is a several-second delay before SendRequest() fails, so it seems to be >sincerely trying to connect to the remote server and not succeeding. I'm >thinking the problem is due to some difference between "https:" and "shttp:". >Any clues? > >Secondly, where can I find out how to send "form data"? I need to generate >automatic responses to a HTML form. I can parse the HTML and figure out what >fields need to be sent, I just don't know how to use the "PUT" or "POST" >methods to actually submit the responses. > >Thanks, > >Jim >jmccabe@mail.portup.com
Mike Blaszczak -- mikeblas@nwlink.com Sunday, August 25, 1996 At 07:17 PM 8/20/96 -0400, you wrote: >a) Because of the AfxParseURL problem, I rephrased my URL using shttp, and > it successfully passed AfxParseURL. Like I said the first time you asked this, this problem is corrected in MFC 4.2a. The MFC 4.2a beta is still bumpy in this area. We're not done making MFC 4.2a: what's been posted to the website is a beta. The final version, which we're still working on, has even more fixes. > b) When using Netscape, when I connect to the site I need to enter a userid > and password. I was passing the correct strings to MFC and forgot to > mention this. HTTPS isn't the same as using authentication on HTTP. Some people combine HTTPS with authentication, and maybe that's what your site is doing. Authetntication means that your request includes a username and password. HTTPS means that you're sending encoded data over the network. HTTPS _and_ Authentication means that you're sending encoded data and that each request includes a username and password. >d) I had previously moaned about the TEAR example, which didn't work. > A couple people from the list responded and told me how to fix the > problem, so I tried it and it works great. What specific problem were you having with TEAR? > However, TEAR was also > not able to connect to the https: site (of course using shttp: instead). > This shouldn't be a surprise, but I thought I'd mention that it was tried. What specific error message did you get? It's really hard to help you because your question contains so little detail. It is _imperative_ that you tell us what error you're getting so that we might be able to guess about what you're doing. For questions dealing with WININET, "can't connect" is hardly enough information. You might have misconfigured WININET to talk to the wrong proxy for HTTPS conversations--you don't mention using a proxy or firewall, even. You might have just given one of the calls a bad parameter. You might have done both. Depending on what error message you're getting and at what step you're having a problem, the matter may simply come down to several different things: a bad configuration, incorrect options when you set up your session, or bad usage of the classes involved. Or some combination of those things. That you can connect using Netscape doesn't say much. Netscape goes to the network using its own implementations of all of the protocols. You should try installing Internet Explorer, which uses WININET.DLL itself to do its communication. If you can connect with Internet Explorer and can't connect with your WININET code, there's something wrong with your code. If you can't get through with Internet Explorer, odds are that you have something on your system incorrectly configured. >>First, is it possible to connect to "https://..." sites? Yes. >>There seems to be >>support for "secure http", but AfxParseURL doesn't recognize "https:". >>However, it does recognize "shttp:". Trying to connect to: See above. >> https://swww.etrade.com/cgi-bin/cgitrade/MainMenu >>... CHttpFile::SendRequest() returns error 12029 ("cannot connect"), even >>though I'm passing INTERNET_FLAG_SECURE to CHttpConnection::OpenRequest(). [snipped] >>thinking the problem is due to some difference between "https:" and "shttp:". >>Any clues? You shouldn't be passing "https:" or "http:" or _any_ scheme name to OpenRequest(). I'm confused: the beginning of your note makes it sound like you're using OpenURL(), but the other part of your note makes it sound like you're using explicit CHttpFile and CHttpConnection calls. The benefit of OpenURL() is that you don't have to worry about other parameters-- there's a lot of work that OpenURL() gets done for you without making you worry about meddling with the other details. It's the classic trade of of more control for more work. >>There is a several-second delay before SendRequest() fails, so it seems to be >>sincerely trying to connect to the remote server and not succeeding. I'm This makes it sound like you're not passing INTERNET_FLAG_SECURE at the right spots. HTTPS and HTTP are not fallback compatible. Since HTTPS is secure, it's tossing around encrypted data all over the place. This looks like garbage to a program that's listening for readable HTTP text response headers, for example, and HTTPS requests are meaningless to a server that is expecting you to send it some plain HTTP. As I mentioned, OpenURL() is busted until 4.2a. You can explicitly get things to work, though, by doing things yourself, for now: void main() { CInternetSession sess("MFC HTTPS Tear Fragment"); try { CHttpConnection* pConnect = sess.GetHttpConnection( "secure.safesite.com", INTERNET_DEFAULT_HTTPS_PORT); CHttpFile* pFile = pConnect->OpenRequest(CHttpConnection::HTTP_VERB_GET, "/cgi-bin/winzip1a", NULL, 1, NULL, NULL, INTERNET_FLAG_SECURE | INTERNET_FLAG_EXISTING_CONNECT ); if (!pFile->SendRequest()) printf("SendRequest() failed\n"); pFile->SetReadBufferSize(4096); // fixed in MFC 4.2a char szBuffer[1024]; while (pFile->ReadString(szBuffer, 1023)) printf("%s", szBuffer); pFile->Close(); delete pFile; delete pConnect; } catch (CException* pEx) { char sz[1024]; pEx->GetErrorMessage(sz, 1024); printf("Exception: %s\n", sz); printf("**** WARNING ****\n"); printf("This sloppily-coded program probably leaked resources and memory.\n"); } } >>Secondly, where can I find out how to send "form data"? The HTTP spec is on http://www.w3.org. It explains what you need to do. .B ekiM http://www.nwlink.com/~mikeblas <--- trip report central 1995 Honda VFR750F (Serial number 00050!) 4 Corners 1996! 1987 Yamaha FZ700 (damaged) AMA, HRC, VFROC These words are my own: I do not speak for Microsoft.
Jim McCabe -- jmccabe@mail.portup.com Wednesday, August 28, 1996 Environment: MSVC 4.2a (4.2 ClassWizard) Win95 First, thanks to Mike B. and all others for your help! I couldn't have done it without y'all and am very thankful for mfc-l. Mike B. wrote: >>d) I had previously moaned about the TEAR example, which didn't work. > >What specific problem were you having with TEAR? This was the bug that made it necessary to call CHttpFile::SetReadBufferSize() before using the file I/O methods. >What specific error message did you get? It's really hard to help you because >your question contains so little detail. Thanks, you're right. I should have posted code to demonstrate exactly what I was doing. In fact, this morning, I tried using your code suggestions (thanks) and still couldn't get things to work. So I downloaded MS Internet Explorer for a final test, since you said it also uses the wininet.dll. As it was being downloaded, I wrote up a message to show the exact calls made by my program. It was funny because CHttpFile::SendRequest() was returning an error code that wasn't even recognized by CInternetException::GetErrorMessage(), and wasn't in the INTERNET_ERROR range. Bit 31 was set, indicating it was a system message. (I can't tell you what number it was now because I can no longer duplicate it, see below.) As long as I tried nonsecure pages things were working fine though. But the message became moot after I got Internet Explorer installed, because suddenly my program started working, without any code changes at all! I'm now able to download the secure web pages with no problems. So it appears that my system was not configured properly somewhere, and the Internet Explorer install process seems to have fixed the problem. Looks like a nice browser, I just wish it let me install to a different location other than "c:\Program Files", because my C: drive was already cramped for space. >The HTTP spec is on http://www.w3.org. It explains what you need to do. Thanks for the tip, and thanks for your patience, Jim jmccabe@mail.portup.com
| Вернуться в корень Архива |