[Webkit-unassigned] [Bug 137299] POST form data is missing with a custom NSURLProtocol

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 3 11:03:13 PST 2014


https://bugs.webkit.org/show_bug.cgi?id=137299

Maciej Stachowiak <mjs at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs at apple.com

--- Comment #27 from Maciej Stachowiak <mjs at apple.com> ---
Two comments on this patch:

(1) Both TwestWebKitAPI and ImageDiffLauncher fail reporting this warning:      1>..\Tests\WTF\MediaTime.cpp(174): warning C4056: overflow in floating-point constant arithmetic

I didn't think warnings would ever cause a build failure on Windows but maybe this is the reason. Perhaps the patch should just be re-uploaded.

(2) If serializing the body is right, I don't think it's correct to do it only for the custom protocol case. As Stuart Morgan mentioned, Chrome for iOS would have a use for it for purposes of the back-forward list even without custom protocols. Since custom protocols are not even supported in the Modern WebKit API at present, I am not sure how the patch posted here would even do anything. Can you explain in what cases it has an effect, and how you tested it?

(3) The patch lacks tests. It should probably have an API test.

(4) If the patch is changed to be global, it probably needs to be performance tested. If the body serialization is a performance hit, we may need to be clever about how to optimize, such as by using shared memory. I think if the patch could be done with no measurable slowdown and worked for even the non-custom-protocol case, likely no one would have a strong objection.

(5) I don't think covering only HTTPBody but not HTTPBodyStream is sufficient for use in a browser, either for custom protocols or for the back/forward case. Any time a form contains a file upload, it will have a body stream. If a client relies on presence of the body, it will fail for this case. While there's no obvious way to serialize an arbitrary HTTPBodyStream, we might be able to special-case detect the one produced by WebKit and convert it back to an array of data chunks and file references.

If we do support passing the body to the client, and possibly eventually support custom protocol handlers for HTTP, I think the feature should be done fully correctly instead of just trying to hit the 90% case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141203/9781b380/attachment-0002.html>


More information about the webkit-unassigned mailing list