Project

General

Profile

Actions

Bug #3461

closed

POST request body corrupted data in Wt::Http::Request

Added by Alan Finley almost 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Roel Standaert
Target version:
-
Start date:
07/11/2014
Due date:
% Done:

0%

Estimated time:

Description

I add a static resource handler for my web app that should accept and parse incoming POST requests:

void
MyHandler::handleRequest(const Wt::Http::Request &request, Wt::Http::Response &response)
{
    std::string data;
    request.in() >> data;
    ...
}

I post a request with some arbitrary content type (except for "application/x-www-form-urlencoded" and "multipart/form-data" which, as docs say, are parsed by Wt automatically):

QNetworkRequest request(url);
request.setHeader(QNetworkRequest::ContentTypeHeader, "application/octet-stream");

QByteArray data = "abcdefghijklmnopqrstuvwxyz";
request.setHeader(QNetworkRequest::ContentLengthHeader, data.size());

QNetworkReply* reply = network->post(request, data);

This works fine when my app is deployed with wthttpd.

But when I deploy my app with wtfcgi, my handler get requests with corrupted data. Request header tells the correct size, but its data is twice less and has every second letter skipped.

I post this: "abcd" and get this: "ac".

Also I've checked nginx logs and used tcpdump to ensure that my data doesn't come corrupted to my Wt app.

I could use "application/x-www-form-urlencoded" header, but according to the RFC if replaces all '+' signs with spaces, so it doesn't meet my needs.

Actions #1

Updated by Koen Deforche over 9 years ago

  • Status changed from New to InProgress
  • Assignee set to Roel Standaert
Actions #2

Updated by Roel Standaert over 9 years ago

  • Status changed from InProgress to Resolved

This is apparently a known (and fixed) issue in libfcgi, the fixed version (2.4.1) simply has never been officially released. (See http://stackoverflow.com/questions/4280975/missing-characters-from-input-stream-from-fastcgi-request) I implemented a workaround that makes it work properly.

Actions #3

Updated by Koen Deforche over 9 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF