search

eddic / fastcgipp

fastcgi++: A C++ FastCGI and Web development platform:
https://fastcgipp.isatec.ca
GNU Lesser General Public License v3.0
310 stars 94 forks source link

Fix crash when client closes connection #22

Closed aspotashev closed 7 years ago

aspotashev commented 7 years ago

The crash occurs when the request is not in the fastcgipp's std::map anymore, and application code sends an empty Fastcgipp::Message(1).

eddic commented 7 years ago

I don't understand what this patch actually does. Can you explain?

aspotashev commented 7 years ago

The commit "Do not interpret message as FastCGI record when message.type != 0" fixes a crash in the following scenario:

  1. A server using fastcgipp is handling FastCGI requests asynchronously.
  2. A client connects to the server and sends a request. Imagine this request is queued in the server application and takes some time before a response is ready.
  3. The client disconnects from the server, thus the respective item is deleted from Manager_base::m_requests.
  4. When the server application is finished processing the request (in another thread), it calls Request::callback()(msg) which in turn calls Manager_base::push(). The msg passed into callback() and push() has the attribute message.type set to 1 because it's a not a FastCGI record (see e.g. fastcgipp/examples/timer.cpp).

While processing such a Message, Manager_base::push() will follow the branch "if(request == m_requests.end()) { ... }" and then attempt to interpret the Message as a FastCGI record (see "reinterpret_cast<Protocol::Header>(message.data.begin());"), even though it's not a FastCGI record and it has no valid message.data.

eddic commented 7 years ago

Alright this makes sense now. I get it. Nice catch! Much appreciated thanks. While trying to work with your fix I noticed another bug as well. Ultimately I fixed it with 3e51cf49 to work around it. Try the new master head and see if it's all well.