> Hallo Okay, you have two choices.
1) You can pipeline, where you send the next request before you receive the entire reply to the previous request. In this case, you may receive the rest of the reply to the first request after you send the second. 2) You can not pipeline, where you don't send the next request until you receive the entire reply to the previous request. In this case, you must keep calling SSL_read until you either get the entire reply, or an error. > I make a request with SSL_write > Servers answers properly. Good. > SSL_read gives 7159 bytes. > SSL_get_error gives allways SSL_ERROR_NONE > and therefor the loop stops > but there are 975 bytes missing. Okay, so you are pipelining. You have allowed the loop to stop before you received the entire reply. > My progamm send next request and then read the response. > > This SSL_read give the missing 975 bytes.:confused: > This next request is ignored, i think If you pipeline, and send the second request before you receive the entire reply to the first request, then you will receive the rest of the first reply, possibly combined with all or parts of the second reply, after you send the second request. If you don't want that, don't pipeline. That is, do not send the second request until you have received the entire first reply. > What happens here ? It's simple. 1) You send the first request. 2) You get part of the first reply. There has been no error. But you end your loop anyway. 3) You send the second request. 4) You get the rest of the first reply, possibly combined with all or part of the second reply. If you don't want this to happen, don't pipeline. Do not break out of the SSL_read loop until you've either read the entire reply or gotten an error. Your error may be a classic TCP error. TCP will not tell you when you've gotten an entire reply. The protocol you are implementing on top of TCP does that. If you are expecting SSL or TCP to somehow tell you "that's the end of the first reply", then it won't do that. It has no way to know. It sounds like you claim HTTP 1.1 compliance when you didn't actually implement HTTP 1.1. HTTP 1.1 requires support for chunked encoding. It requires that either chunked encoding or a content length header be used and understood by the client to mark the end of the reply. It also specifies that where neither of these things happen, the end of a reply is marked by the connection closing. Perhaps you should set your sights lower and implement HTTP 1.0 which does not require this level of support. Otherwise, use an HTTP library that properly supports HTTP 1.1. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
