Commented Issue: [Win32] http_listener crashes upon complicated query string [267]

When a request for a complicated string such as
```
http://localhost:4999/?callback=localJsonpCallback&{%22LastName%22:%22O%20Flynn%22,%22FirstName%22:%22Michael%22,%22Age%22:23}&_=1409855883776
```
is received, the URI parser fails and throws an exception. This exception cannot be caught and promptly crashes the program.

Stack trace:
```
cpprest120d_2_2.dll!web::uri::uri(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & uri_string) Line 112 C++
cpprest120d_2_2.dll!web::uri_builder::to_uri() Line 129 C++
cpprest120d_2_2.dll!web::http::experimental::details::windows_request_context::read_headers_io_completion(unsigned long error_code, unsigned long __formal) Line 542 C++
cpprest120d_2_2.dll!web::http::experimental::details::windows_request_context::async_process_request::__l3::<lambda>(unsigned long error, unsigned long nBytes) Line 502 C++
cpprest120d_2_2.dll!std::_Callable_obj<void <lambda>(unsigned long, unsigned long),0>::_ApplyX<void,unsigned long,unsigned long>(unsigned long && <_Args_0>, unsigned long && <_Args_1>) Line 284 C++
cpprest120d_2_2.dll!std::_Func_impl<std::_Callable_obj<void <lambda>(unsigned long, unsigned long),0>,std::allocator<std::_Func_class<void,unsigned long,unsigned long> >,void,unsigned long,unsigned long>::_Do_call(unsigned long && <_Args_0>, unsigned long && <_Args_1>) Line 229 C++
cpprest120d_2_2.dll!std::_Func_class<void,unsigned long,unsigned long>::operator()(unsigned long <_Args_0>, unsigned long <_Args_1>) Line 315 C++
cpprest120d_2_2.dll!web::http::experimental::details::http_overlapped::io_completion_callback(_TP_CALLBACK_INSTANCE * instance, void * context, void * pOverlapped, unsigned long result, unsigned long numberOfBytesTransferred, _TP_IO * io) Line 88 C++
```
Comments: The query string doesn't have to be complicated, just illegal. Something like http://localhost:4999/?^ is enough to trigger the behavior. (The "^" is not a legal character in the query part of a URI. In the original example, "{" and "}" are probably the culprits. See http://tools.ietf.org/html/rfc3986#section-3.4.)