18,363
社区成员
发帖
与我相关
我的任务
分享调用HttpOpenRequest后，GetLastError()得到122，为什么？
函数工作是正常的，接下来POST数据也是对的，但是调用HttpQueryInfo时，得不到状态码，GetLastError()也是得到122
代码如下：
HINTERNET hRequest = HttpOpenRequest(hConnect, "POST", lpPath,
NULL, NULL, NULL, INTERNET_FLAG_NO_CACHE_WRITE, 1);
DWORD dwErr = ::GetLastError();//此处得到122
DWORD dwCode, dwLen;
dwLen = sizeof(dwCode);
::HttpQueryInfo(hRequest, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER, &dwCode, &dwLen, NULL);
TRACE("状态码是%d\n", dwCode);//dwCode为0
dwErr = ::GetLastError();//此处得到122
----
这样就得不到合法的状态码，无法判断服务器地应答
代码如下：
HINTERNET hRequest = HttpOpenRequest(hConnect, "POST", lpPath,
NULL, NULL, NULL, INTERNET_FLAG_NO_CACHE_WRITE, 1);
DWORD dwErr = ::GetLastError();//此处得到122
DWORD dwCode, dwLen;
dwLen = sizeof(dwCode);
::HttpQueryInfo(hRequest, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER, &dwCode, &dwLen, NULL);
TRACE("状态码是%d\n", dwCode);//dwCode为0
dwErr = ::GetLastError();//此处得到122
----
这样就得不到合法的状态码，无法判断服务器地应答
...全文
请发表友善的回复…
发表回复
DoubleJiang 2004-07-22
- 打赏
- 举报
up
sjzxyg 2004-07-22
- 打赏
- 举报
HttpOpenRequest后操作都是成功的，为什么还返回122（传递到系统调用的数据区太小）
UDX协议 2004-07-22
- 打赏
- 举报
The member function bGetData does most of the class's work. To retrieve the HTTP header information, it needs to create an HTTP request, submit this request to the Web server, and get the values for the HTTP headers. We can optionally get the server to send the default HTML file. The HttpOpenRequest API is used to create the request. We need to specify the method for the transaction request and an object of the request. In our case we use the GET method and specify an empty string as the URI for the request. The empty string will allow us to receive the default file from the Web server. Note that this file name can have different formats. For example, UNIX-based Web servers usually use .html, while Windows-based servers use .htm. After the request is built, we use the HttpSendRequest API to actually send it.
You can see the details of an HTTP request using Network Analyzer. Figure 7 shows the Network Analyzer output of a similar GET request. We'll go over this trace a little later. Once the Web server receives a request, it sends its default HTML data back to WebSpy. Since HTTP transaction headers are not a part of the HTML file, they cannot be seen in the received text, so we need to use HttpQueryInfo to spy on the header information. This API can get either a specific header or all of them. The rather unwieldy HTTP_QUERY_RAW_ HEADERS_CRLF parameter indicates that we are interested in all headers, and we want them to be separated by a CR/LF. Before we can specify the buffer to write the information to, our buffer needs to be allocated. We use the HttpQueryInfo API, setting the third parameter to NULL, to find out how much memory needs to be allocated. Even though this call fails with error 122, "The data area passed to a system call is too small," the returned dwSize parameter indicates the necessary size for all the available data.
Our second task is to get the HTML text of the default server document. We can use InternetReadFile for this purpose, passing in the handle returned by the HttpOpenRequest call. Just as with the headers, we need to supply a buffer of the proper size for the call to succeed. This is an easy task since the size of the default HTML file is stored in the Contents-Length header. We can either parse the complete list of headers returned by our previous call or just call HttpQueryInfo again with the HTTP_QUERY_CONTENT_LENGTH parameter. In our case, the length is returned as an ASCII value so we convert it to its numeric representation. It is worth mentioning that HttpQueryInfo can also return numeric values.
DWORD statusSize = sizeof (dwSize);
HttpQueryInfo ( hReq, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER ,
(LPVOID)&dwSize, &statusSize, NULL)
Once the buffer contains the HTML text sent by the server, we are almost ready to display it in the edit box. There is a little catch, though. Remember that in the text file on UNIX-based servers, lines are separated from each other by only a line feed character. On Windows and MS-DOS®-based machines, lines of text files are separated by the CR/LF pair. To output the buffer in a nicely formatted form, we'll go over the buffer and see if we need to insert carriage returns.
All that's left is to delete the memory buffers and close the Internet connection handles. The InternetCloseHandle API is used to kill them, since the normal Win32® CloseHandle function cannot be applied to an Internet handle. Closing the parent handle with InternetCloseHandle is enough to not only close the parent handle, but also to close all the parent's child handles as well. However, if you have any asynchronous requests outstanding on this or any other child handle, all those outstanding requests must finish before InternetCloseHandle completes.
The code below demonstrates this common error with the parent-child handle relationship:
...
hOpen = InternetOpen ()
hConnect = InternetConnect ( hOpen, …);
...
In this code, hOpen is parent handle. Closing it will invalidate the hConnect handle. The code shown below will generate an error 6, "The handle is invalid", on closing the hConnect handle:
...
InternetCloseHandle (hOpen );
InternetCloseHandle (hConnect );
...
At this point we know how WebSpy does its job. Let's take a look at the Microsoft Network Monitor trace in Figure 7 and see how we can read it. The trace indicates that WebSpy generates an HTTP GET request. In this case, HTTP packets are carried to the destination by the underlying TCP connection-oriented protocol. Network Monitor gives us the opportunity to peek into the HTTP packet and see all the headers.
The
header indicates the URL that brought us to this destination. You can use it in your application to see how clients are getting to your particular page. In this case it's blank since we directly initiated the connection to the server's default file by typing into the browser's address field. The next header is Pragma: no-cache. It indicates that all proxies, gateways, and firewalls should get the data from the actual Web server and not from a cache. Host indicates a destination machine for our request. User-Agent identifies the browser application. This name is specified in the InternetOpen call as one of the API parameters. Web servers can get this header for statistic purposes, or you can write a filter that allows only certain types of clients to connect and get information.
One more feature of the Network Analyzer is the ability to show the hexadecimal and ASCII representations of the data. In our case we can see that the headers are separated from each other by the CR/LF pair (0D 0A in hex) and the very last header is followed by two CR/LF pairs.
Let's take a look at the information sent to WebSpy by the server (see Figure 8). To transfer the default file from the server, more than one TCP packet is needed. We will only look at the first packet since it contains all the headers information we are interested in. As in the GET request, the server's response comes as HTTP on top of TCP. As we can see, WinInet communicates with the server using HTTP 1.0. This particular transaction completed successfully, which we can see by looking at the Status Code OK. (Note the numeric 200 value for the OK code in the binary dump.) All these pieces of information about the transaction status and protocol version look like this in the WebSpy window:
HTTP/1.0 200 OK
You can see the details of an HTTP request using Network Analyzer. Figure 7 shows the Network Analyzer output of a similar GET request. We'll go over this trace a little later. Once the Web server receives a request, it sends its default HTML data back to WebSpy. Since HTTP transaction headers are not a part of the HTML file, they cannot be seen in the received text, so we need to use HttpQueryInfo to spy on the header information. This API can get either a specific header or all of them. The rather unwieldy HTTP_QUERY_RAW_ HEADERS_CRLF parameter indicates that we are interested in all headers, and we want them to be separated by a CR/LF. Before we can specify the buffer to write the information to, our buffer needs to be allocated. We use the HttpQueryInfo API, setting the third parameter to NULL, to find out how much memory needs to be allocated. Even though this call fails with error 122, "The data area passed to a system call is too small," the returned dwSize parameter indicates the necessary size for all the available data.
Our second task is to get the HTML text of the default server document. We can use InternetReadFile for this purpose, passing in the handle returned by the HttpOpenRequest call. Just as with the headers, we need to supply a buffer of the proper size for the call to succeed. This is an easy task since the size of the default HTML file is stored in the Contents-Length header. We can either parse the complete list of headers returned by our previous call or just call HttpQueryInfo again with the HTTP_QUERY_CONTENT_LENGTH parameter. In our case, the length is returned as an ASCII value so we convert it to its numeric representation. It is worth mentioning that HttpQueryInfo can also return numeric values.
DWORD statusSize = sizeof (dwSize);
HttpQueryInfo ( hReq, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER ,
(LPVOID)&dwSize, &statusSize, NULL)
Once the buffer contains the HTML text sent by the server, we are almost ready to display it in the edit box. There is a little catch, though. Remember that in the text file on UNIX-based servers, lines are separated from each other by only a line feed character. On Windows and MS-DOS®-based machines, lines of text files are separated by the CR/LF pair. To output the buffer in a nicely formatted form, we'll go over the buffer and see if we need to insert carriage returns.
All that's left is to delete the memory buffers and close the Internet connection handles. The InternetCloseHandle API is used to kill them, since the normal Win32® CloseHandle function cannot be applied to an Internet handle. Closing the parent handle with InternetCloseHandle is enough to not only close the parent handle, but also to close all the parent's child handles as well. However, if you have any asynchronous requests outstanding on this or any other child handle, all those outstanding requests must finish before InternetCloseHandle completes.
The code below demonstrates this common error with the parent-child handle relationship:
...
hOpen = InternetOpen ()
hConnect = InternetConnect ( hOpen, …);
...
In this code, hOpen is parent handle. Closing it will invalidate the hConnect handle. The code shown below will generate an error 6, "The handle is invalid", on closing the hConnect handle:
...
InternetCloseHandle (hOpen );
InternetCloseHandle (hConnect );
...
At this point we know how WebSpy does its job. Let's take a look at the Microsoft Network Monitor trace in Figure 7 and see how we can read it. The trace indicates that WebSpy generates an HTTP GET request. In this case, HTTP packets are carried to the destination by the underlying TCP connection-oriented protocol. Network Monitor gives us the opportunity to peek into the HTTP packet and see all the headers.
The
header indicates the URL that brought us to this destination. You can use it in your application to see how clients are getting to your particular page. In this case it's blank since we directly initiated the connection to the server's default file by typing into the browser's address field. The next header is Pragma: no-cache. It indicates that all proxies, gateways, and firewalls should get the data from the actual Web server and not from a cache. Host indicates a destination machine for our request. User-Agent identifies the browser application. This name is specified in the InternetOpen call as one of the API parameters. Web servers can get this header for statistic purposes, or you can write a filter that allows only certain types of clients to connect and get information.
One more feature of the Network Analyzer is the ability to show the hexadecimal and ASCII representations of the data. In our case we can see that the headers are separated from each other by the CR/LF pair (0D 0A in hex) and the very last header is followed by two CR/LF pairs.
Let's take a look at the information sent to WebSpy by the server (see Figure 8). To transfer the default file from the server, more than one TCP packet is needed. We will only look at the first packet since it contains all the headers information we are interested in. As in the GET request, the server's response comes as HTTP on top of TCP. As we can see, WinInet communicates with the server using HTTP 1.0. This particular transaction completed successfully, which we can see by looking at the Status Code OK. (Note the numeric 200 value for the OK code in the binary dump.) All these pieces of information about the transaction status and protocol version look like this in the WebSpy window:
HTTP/1.0 200 OK
