On Wed, 14 Nov 2007 21:33:29 -0800 (PST), lanclot
<wi*******@gmail.comwrote:
<snip>
sprintf(request, "POST /accounts/ClientLogin HTTP/1.0\r\nContent-
length:1344\r\nContent-type: application/x-www-form-urlencoded\r
\na********************************************@si na.com&Passwd=031126&service=lh2&source=sd4-
aa-1.0\r\nHost: %s:%d\r\nConnection: Close\r\n\r\n",
host_addr,portnumber);
<ontopic>
You still haven't shown the declaration and if applicable allocation
of request. Unless it points to a sufficient number of writable char's
for the data sprintf puts there, you have Undefined Behavior.
<offtopic>
If it does, you have a bogus HTTP/1.0 request.
Most seriously you have data intermixed with the headers. POST data
must follow the end of header (\r\n\r\n *) and content-length's value
must give its length; your data here is nowhere near 1344 chars=bytes.
(* Technically, CR LF CR LF; like many Internet protocols HTTP is
defined in ASCII or an extension thereof, while C does not require
ASCII so \n and \r in C could actually be newline and return in some
different character set, and not the correct codes for HTTP -- but not
on systems you're likely to use.)
Also, Host: is not defined for 1.0, and if the server supports it as
an extension compatible with 1.1 putting an _address_ in it rather
than a (domain) name defeats the purpose for which it was defined.
Finally, Connection: is not standard in 1.0 and the default is already
equivalent to connection=close.
</>
if (DEBUG)
printf("%s", request); /* prepare request£¬ */
Minor point: requests with body don't need to end with an end-of-line
(\n in C), so you probably want to add one at least conditionally.
Formally C allows an implementation to not support/allow text files
where the last line doesn't end with a newline; in practice most do,
almost certainly including yours, but it's still confusing and ugly.
if (host_file && *host_file)
pt = Rstrchr(host_file, '/');
else
pt = 0;
If (nonstandard) Rstrchr doesn't do something very much like the
standard strchr, it is confusingly named. If it does ...
memset(local_file, 0, sizeof(local_file));
if (pt && *pt) {
.... this test is redundant; if pt was set to point to a character in a
string then both pt != NULL and *pt != '\0'; if it was set to 0 then
pt == NULL (and *pt must not be and is not tested).
if ((pt + 1) && *(pt + 1))
.... and so is this. If pt points to a character in a string and is
necessarily nonnull, then pt+1 is also nonnull. Checking *(pt+1) is
useful, although pt[1] is equivalent and arguably more idiomatic.
strcpy(local_file, pt + 1);
else
memcpy(local_file, host_file, strlen(host_file) - 1);
You really want to use all but the last character of (the contents of
or value pointed to by) host_file? That seems odd.
<snip>
i = 0;
/* connected£¬response https */
while ((nbytes = SSL_read(ssl, buffer, 1)) == 1) {
<semi-offtopicCalling SSL_read for each character will probably
waste quite a bit of CPU, at least assuming this is openssl as it
appears. (Openssl in particular is offtopic, but IMO the general
concept of few large calls versus many small ones is ontopic.) </>
if (i < 4) {
if (buffer[0] == '\r' || buffer[0] == '\n')
i++;
else
i = 0;
if (DEBUG)
printf("%c", buffer[0]); /*print https header
info */
} else {
fwrite(buffer, 1, 1, fp);
i++;
if (i % 1024 == 0)
fflush(fp);
}
}
This doesn't make sense. It appears you are trying to use the same
variable, i, both to count data received/written and count consecutive
\r and \n to find end-of-header. Those are conflicting uses.
Also, flushing output every 1024 bytes is dubious. 1024 doesn't have
any particular significance to the HTTP format, except by the remotest
chance; and while it might matter to the buffering done by stdio,
stdio will already flush whenever it needs to based on its (actual)
buffering without you even thinking about it -- that's one of the
reasons for having and using stdio in the first place.
fclose(fp);
- formerly david.thompson1 || achar(64) || worldnet.att.net
