-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ProtocolException unsupported HTTP version #101
Comments
I've been looking into this one a bit, unfortunately I don't think I know how to fix it. With the debugger I got to this point: restc-cpp/restc-cpp/src/IoReaderImpl.cpp:31 and the state of some variables:
I got into this function twice before this one and data in buffer_ looked fine (a valid string starting with HTTP). What could be going wrong here? Is it a lib or a server problem? This is a blocker for me as it's preventing my program from running correctly with the real server, please help! Edit I've been debugging a bit more, it's boost itself that fills the buffer like that, so it doesn't look like some memory corruption or anything of the sort to me, but I'm still clueless on what the cause might be Edit 2 on a second thought it could be some kind of body length? meaning empty? I can't see that happening in curl, but it could be something that curl just skips over or it's only caused by the way this lib/boost communicate with the server? I think it's weird to have that even before the HTTP string, but it's consistent and curl just works Edit 3 ok I'll stop looking now, but I'm starting to think it might be something like the server sending chunked replies without explicitly saying so? could that be? so the wrong reader gets instantiated and it chokes on the chunk sizes? this part leaves me a bit confused: "For version 1.1 of the HTTP protocol, the chunked transfer mechanism is considered to be always and anyway acceptable, even if not listed in the TE (transfer encoding) request header field" - anyways, I'm just guessing here! |
Any chance to get some comment on this please? Like I said, this is a blocker for me, it stalled my whole project |
Did you find a solution for this issue? I've run up against it in my project. |
I'm working on it. (I can only reproduce it under Windows). |
yes, I'm having the issue with Windows and VS2019. |
Hi,
|
It's been a long time and since that problem was a hard blocker for me I simply ditched restc-cpp and implemented my own solution using libcurl and simdjson. My program's been running for a few months now collecting 1.3 GiB of compressed JSON. It only quits every few days/weeks due to unrelated bugs. For those interested my code is here. Specifically you want to look at quick_rest.hpp, the interface is very simple and it enables me to do everything I need. Result is a string with the received http code attached and some other fun stuff. Json parsing is done outside, by the function that invokes To be exact I put restc-cpp facing code inside ifdefs so I could go back to it. I can still give the latest version of restc-cpp a try, but iirc there was also the problem of getting the appropriate http code in case of bad response by the server, which prevents me from reacting properly to errors. |
I'm obtaining the same error. This happens when I this piece of code:
I can obtain two type of body strings. One is an empty array
The other response is something like this
When I receive this, I obtain the exception, but if I comment the |
It says unsupported http version. Can you enable logging or use the debugger to see what http version the server is using in the http reply ? |
As I've said, it's the same error. The problem occurs because in the new piece of code
|
I've replaced |
Weird. The string contains a zero, which indicate a bug at a lower level in the code parsing the HTTP response. I think I better try to reproduce the problem here. |
This is an extract of the piece of code where I had problems:
I'm using Visual Studio 2022 (17.3.3) with Windows 11 64 bit |
It helps when I substitute reply->GetBodyAsString() with
|
Hello, I'm trying to connect to a remote server and my program fails with this exception:
Is the upstream server misconfigured, or should this library be able to clean up the extra characters before HTTP?
The text was updated successfully, but these errors were encountered: