1
Vote

http_listener crashes when URI contains a pending square bracket

description

When a square bracket is present at the last position in the URI, http_listener throws an uri_exception which isn't catched, thus the program is terminated (as of Casablanca 2.5.0). Somehow Http Server API seems to allow a pending "[" or "]" in CookedUrl.pFullUrl on Window 7.

The fix seems to be trivial:

void windows_request_context::read_headers_io_completion(DWORD error_code, DWORD)
{
if(error_code != NO_ERROR)
{
    m_msg.reply(status_codes::InternalError);
}
else
{
    try    // FIX:::
    {
        // Parse headers.
        // CookedUrl.pFullUrl contains the canonicalized URL and it is not encoded
        // However, Query strings are opaque to http.sys and are passed as-is => CookedUrl.pFullUrl
        // contains an already encoded version of query string.
        uri_builder builder(uri::encode_uri(m_request->CookedUrl.pFullUrl));
                     .....
    }
    catch (...)   // FIX:::
    {
        // mrkkrj, 08/24/2015
        // possible, Http Server API seems to allow a pending "[" or "]" in CookedUrl.pFullUrl!!!
        m_msg.reply(status_codes::BadRequest);
    }
  }
}

comments

mrkkrj wrote Aug 26, 2015 at 10:02 AM

Wait, wait, somehow it is not possible to reply with an error out of this context - m_msg.reply() never sends anything out, and if we try to get sync on it with wait(), it seems to be hanging.

So no trivial fix here?

Marek

mrkkrj wrote Aug 27, 2015 at 6:33 AM

Correct way to respond in that context seems to be:
m_response = http::http_response(status_codes::BadRequest);
async_process_response();   
Marek

roschuma wrote Aug 27, 2015 at 11:04 PM

Do you have a small test case which repros this behavior and demonstrates that the error can't be caught by wrapping the api usages with try/catch?

mrkkrj wrote Sep 3, 2015 at 7:36 AM

not yet, I'll make one.

BTW: I cannot wrap the API with try/catch, because the code runs before dispatch_to_listener() is even called.

gigaplex wrote Nov 13, 2015 at 7:48 AM

I'm pretty sure 2.6.0 fixes the exception, and https://github.com/Microsoft/cpprestsdk/pull/16 fixes the fact that the reply wasn't actually sent.