| commit | d1184e0d91046b5f917900624670ccce0fd25d70 | |
| author | Alan Frindell <afrind@fb.com> | |
| Fri, 7 Feb 2014 20:08:18 +0000 (7 12:08 -0800) | ||
| committer | Sara Golemon <sgolemon@fb.com> | |
| Mon, 10 Feb 2014 17:44:27 +0000 (10 09:44 -0800) | ||
| tree | f6556db8c39bd50c9c77ee85d6a2f76e358db7d0 | treesnapshot (tar.gz zip) |
| parent | a808174fffab3a847d0d97b46f89c3a35f7265e5 | commitdiff |
Correctly handle invalidated POST data on upload path
DecodeRfc1867 was returning a data and length pointer that were being copied and saved for use with php://input. In the case where AlwaysPopulateRawPostData is false, data will actually point to the last chunk received, but size will be the cumulative size of the post. There's nothing meaningful that can be done with this data, just ignore it.
The data copy immediately prior to DecodeRfc1867 was unecessary when AlwaysPopulate was off, but for a silly realloc call in read_post. Reworked this case to avoid the realloc/memcpy and just read directly from the network buffer. While I was there, I corrected some integer types that could cause problems for POSTs > 2GB.
Reviewed By: @ptarjan
Differential Revision: D1164497
DecodeRfc1867 was returning a data and length pointer that were being copied and saved for use with php://input. In the case where AlwaysPopulateRawPostData is false, data will actually point to the last chunk received, but size will be the cumulative size of the post. There's nothing meaningful that can be done with this data, just ignore it.
The data copy immediately prior to DecodeRfc1867 was unecessary when AlwaysPopulate was off, but for a silly realloc call in read_post. Reworked this case to avoid the realloc/memcpy and just read directly from the network buffer. While I was there, I corrected some integer types that could cause problems for POSTs > 2GB.
Reviewed By: @ptarjan
Differential Revision: D1164497
| hphp/runtime/server/http-protocol.cpp | diffblobblamehistory | |
| hphp/runtime/server/upload.cpp | diffblobblamehistory |