Re: Protocols.HTTP.Server.SSLPort and connection: close header

Hi Stefan,

I can confirm this problem on 8.0.462... the problem is that the SSL module can report that data has been written before it actually goes out on the wire (I also just confirmed the documentation for SSL.File->write() describes this behavior... so the HTTP module thinks the data is sent and closes the connection.

The following change seems to work with small payloads on a fast network. I don't think it's the ultimate solution, though.

in Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike, function send_write():

change

  finish(sent==send_stop);

to

  call_out(finish, 0, sent==send_stop);

This basically tacks the code that closes the socket to the end of the next backend run, and any asynchronous sending that the SSL module has to do should be in front of it. Obviously, this only works if it only takes one backend run to send the data. 

A (possibly) better approach would be to wait for the next write callback and do the close then. I'm not aware of a method that returns whether the SSL.File buffers have been flushed, so this may be as good a solution as is available right now.

Bill

January 26, 2018 5:19 AM, "Stefan Gluszek" <[email protected]> wrote:

> Hi,
> I have an issues with using the HTTP SSLPort together with connection:
> close header.
> 
> So I set up a simple HTTPS server using the SSLPort:
> 
> void got_connection(Protocols.HTTP.Server.Request r)
> {
> mapping m = ([
> "data": "test",
> ]);
> 
> r->response_and_finish(m);
> }
> 
> void new_connection()
> {
> werror("new_connection\n");
> }
> 
> int main()
> {
> Protocols.HTTP.Server.SSLPort ssl_port;
> ssl_port = Protocols.HTTP.Server.SSLPort(got_connection, 9999);
> return -1;
> }
> 
> Now making a request with connection: close I get an empty reply from my server.
> curl -k -H "Connection: close" https://localhost:9999
> wget --no-http-keep-alive --no-check-certificate https://localhost:9999
> 
> Shouldn't that work? Is there anything I am missing? Making a similar
> request to apache seems to work just fine.
> 
> /Stefan