I am writing an apache module and I am wondering how to handle the case where my ap_rwrite tries to write something back to the client and the client does not respond to it.
Does the call to ap_rwrite block until that happens?
Can I set a timeout on that? If so, what is it called?
Thanks!
The client does not respond to server again. HTTP is a request-response protocol, the client send a request to the server and server sends a response to client. Client should not respond to server.
If you mean how to know if the client receives the response maybe you can alter the default timeout, but if the socket is closed or other network error, the function 'ap_rwrite' will notice you with an error.
Related
I'm using apache camel xml based paho routes for the subscription, publication process. While online, everything works fine. But I'm not able to receive the offline message.
I have set the following.,
Constant Client ID
Clean Session is FALSE,
Both subscribed & published with QoS 2
With the standalone Program, it's getting all the offline messages. With the camel route it's not happening.
Finally, I was able to solve this one manually.
Camel PAHO Client is not populating the callback function before performing the broker connection. They are doing it only when the connection is made.
So, once the connection is success then the broker just sends all the offline messages. In this case, our client does not have callback handlers to handle these messages. So they are lost.
Other clients (IoThub Client) which uses the PAHO internally is doing it right by setting the callback and initiating the connection.
I have a problem with making HTTPS requests from the client to the server.
My server is using Winsock with OpenSSL on top of the sockets, while my client is using WinHttp library. All these are done in C.
Below is a description of what happened (or how I understood it to be) at the server and client during a network communication:
At the server side, the application is blocked at accept() while waiting for connection to be made from the client. On the first HTTP request made by client using WinHttpSendRequest(), the accept() unblocks and creates a new thread. Then, accept() went into blocking state again until a new client connects to it.
In the thread at the server side, recv() receives the packet sent over by the client, then it sends over a response packet via send().
Upon receiving the response packet from server, WinHttpSendRequest() at the client side unblocks, before moving on to execute WinHttpReceiveResponse() and the rest of the code to read in the content of the response packet.
Meanwhile, recv() at the server side blocks until client sends over another request via WinHttpSendRequest(), and this goes on to and fro until the server sends a command to terminate the client.
This mechanism of using Winsock at the server side and WinHttp at the client side works for sending multiple HTTP requests from client to server over the same connection.
However, when I decided to add in a layer of encryption for this network communication, ie. client sends HTTPS instead of HTTP requests over, and server uses openSSL functions to receive and send packets (SSL_read() in replacement of recv() and SSL_write in replacement of send()), each time the client makes a WinHttpSendRequest(), accept() at the server side will unblock and return a new socket. In the previous scenario where encryption was not done and requests were HTTP, accept() at the server side will only unblock when it is the first request made by a new client; subsequent requests by the same client will be received through the blocking and unblocking of recv().
Just some things to note: For my client side, I have kept the handles for WinHttpOpen and WinHttpConnect open, while those of WinHttpOpenRequest and WinHttpSendRequest will be closed after each request and recreated for each new request. Also, packets received for both sides can be read properly after encryption (I know encryption was done as packets sniffed by Wireshark is unreadable).
I have been searching all over the internet to see if anyone has experienced the same thing, but to no avail :( Is there anyone who can explain to me why this is happening?
I'm working on an embedded application (running MQX RTOS, written in C) which has SMTP functionality. Recently, TLS support was added using the Mocana NanoSSL library. I'm currently able to successfully send emails using Gmail, Yahoo, and private exchange servers. Unfortunately, Hotmail does not work. Here's the connection parameters i've used:
Server: smtp.live.com
Port: 25 and 587
AUTH method: PLAIN and LOGIN
Basically, i'm able to successfully connect to the server, perform the SSL/TLS handshake (using STARTTLS), and send the encrypted EHLO message to the server (receiving a response). According to this response, the server supports both AUTH PLAIN and AUTH LOGIN. However, once I send either of these commands, the following SSL_recv() call I make to get the response fails with either a timeout or connection reset by peer.
UPDATE:
OK, so after some experimentation it would appear that my issue lies at the SSL library level and not with Microsoft's SMTP server. I tried replacing the SSL_recv() calls with standard RTCS socket recv() calls and was able to receive and view encrypted data. By disabling my response verification, I was then able to continue through the SMTP process and successfully send a message. At this time i'm not sure why the SSL_recv() calls are unable to get the socket data, but i'll keep digging and will hopefully find an answer.
Well, I also got it working here too. I had to replace the
ssl_ctx=SSL_CTX_new(SSLv23_client_method());
with either:
ssl_ctx=SSL_CTX_new(SSLv3_client_method());
or
ssl_ctx=SSL_CTX_new(TLSv1_client_method());
My understanding is that the 23_client method sends a SSL2 client hello first and this confuses the server.
I read this in the HP SSL programming tutorial:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
it says: "However, the SSL client using the SSLv23 method cannot establish connection with the SSL server with the SSLv3/TLSv1 method because SSLv2 hello message is sent by the client."
SSL3 works too since you can continue after STARTTLS with SSL, you do not have to use TLS.
See here:
https://www.fastmail.fm/help/technology_ssl_vs_tls_starttls.html
So, it's the SSL library itself that appears to be failing me here. I was able to bypass the issue and successfully send email by simply not calling SSL_recv() to verify the server responses. I'm obviously not able to error check or get any meaningful failure feedback, but for a successful use case where the server accepts all of my SMTP messages the email is sent.
We observe that the TCP connections are sometimes reset by Google Application Engine. The exact behavior is following:
TCP handshake is done (SYN, SYN/ACK, ACK)
Http POST is sent by client
Google Application servlet sends RST
See the attached screenshot. Any reason for that? Should we simply send the POST request again on client?
BR
STeN
I must develop proxy server that work with only HTTP 1.0 in Linux and by c .
I need some hint to start developing .
I assume you are confident in using linux and the language c (no hints for that, else don't start with developing a proxy)
Read and understand the RFC 1945 HTTP/1.0 (pay attention to the specific mentioning of proxy)
Determine what kind of proxy you want (web/caching/content-filter/anonymizer/transparent/non-transparent/reverse/gateway/tunnel/...)
Start developing the server
Basic steps
Open port
Listen on port
Get all request sent from the client to that port (maybe make the whole thing multithreaded to be able to handle more than 1 request at a time)
Determine if it is a valid HTTP 1.0 request
Extract the request components
Rebuild the request according to what type of proxy you are
Send the new request
Get the response
Send response to client
How to create a proxy server:
Open a port to listen on
Catch all incoming requests on that report
Determine the web address requested
Open a connection to the host and forward the request
Receive response
Send the response back to the requesting client
Additionally: Use threads to allow for multiple requests to the server.