Hello all,
I found myself interacting with a HTTP server that returns 100 Continue responses to HTTP POST requests. The pike HTTP client treats those as the final response, but they’re are meant to be considered intermediate responses. I couldn’t figure out if there was a way to get it to continue past that, and it doesn’t look like there is. The standard says a server shouldn’t send them if they aren’t requested, but also says that clients must treat them as informational and carry on.
I have a proposed fix, but since that’s a messing with a pretty widely used bit of code, I wanted to get feedback before I start making changes. I don’t know if there are other similar scenarios that this fix doesn’t cover; I’d be happy to hear feedback on that as well.
In Protocols.pmod/HTTP.pmod/Query.pike, following this line:
int bytes_read = sscanf(headerbuf,"%s%*[ ]%d%*[ ]%s%*[\r]",protocol,status,status_desc);
add:
// we don't expect continue responses, but we must deal with them, // and treat them as informational if(status == 100) { int q = sizeof(headerbuf);
// find the end of the response message, and move past the newlines present. // since the whole request has been sent already, we just have to wait for the response, // if it isn’t already in the buffer. Either way, there should be trailing line endings, // as those were required to be present for us to have gotten this far. while(q < sizeof(buf)) { if(buf[q] == '\n' || buf[q] == 'r') continue; break; }
// reset the buffer to the point just past the continue response and start over. buf = buf[q+1..];
// a better approach might be a do-while loop, but this is a bit clearer, // and we shouldn't find ourselves recursing more than once. return ponder_answer(); }
I think this affects all versions of pike (certainly 8.x and 9.x).
Thanks in advance!
Bill