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
| Вернуться в корень Архива
|