Bug 140188

Summary:	HTTP body/bodystream (e.g., POST form data) is missing in WKNavigationDelegate callbacks
Product:	WebKit	Reporter:	Stuart Morgan <stuartmorgan>
Component:	WebKit2	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Major	CC:	ap, bahuto, bugzilla, chinnu, christiebrwn80, davidkclark, deannawilliam12, dieter, emmarobet07, eric.carlson, etm61801, gaxifovir, generatorherexyz, gracieflora19, iamvishakha5555, ibaddani665, jason.bugzilla, jm398964, juliejennifer666, kayleebryson81, kemiwe, mariadenial1123, matthew, mauvetreeofficial, megazlo, m.goleb+bugzilla, myersco3, pswag994, rebeccahickshq, sagarharish999, saleonleather, s.alpieiev, sandyjames00, stephaniejshawww, stephanyortega483, taruncoupns, vfv12130, webkit-bug-importer
Priority:	P2	Keywords:	InRadar
Version:	528+ (Nightly build)
Hardware:	iPhone / iPad
OS:	All
See Also:	https://bugs.webkit.org/show_bug.cgi?id=137299 https://bugs.webkit.org/show_bug.cgi?id=179077

Description Stuart Morgan 2015-01-07 11:32:23 PST

Spun off of bug 1377299, POST data and any other HTTPBody or HTTPBodyStream is missing from NSURLRequest objects provided in the WKNavigationDelegate.

STR:
- Implement a WKNavigationDelegate
- Submit a form
- In webView:decidePolicyForNavigationAction:decisionHandler:, try to extract the form data via navigationAction.request.HTTPBody

None of the data is there (apparently by design, per comment 5 in the other bug).


This is a serious problem for Chromium, since we implement our own back/forward handling (for a variety of reasons, a significant one being the ability to sync tabs with history across devices, and to re-create tabs with full history across cold launches of the app--since there's no way to edit the history of a WKWebView, only read it, maintaining our own stack is our only option). This bug means that going back or forward to a page that includes any kind of HTTP body will fail to work correctly.

This is also filed as rdar://18399639

Comment 1 jason.bugzilla 2015-08-19 14:28:04 PDT

Any update on this? This seems like it is blocking a fair number of people and really making WKWebView incomplete for many developers.

If not, is there a good workaround? This seems pretty terrible to me:
http://stackoverflow.com/questions/26253133/cant-set-headers-on-my-wkwebview-post-request

Comment 2 Stuart Morgan 2015-08-20 06:32:06 PDT

Based on the link, it sounds like you are looking for bug 145410 rather than this one.

Comment 3 David 2016-02-03 13:52:02 PST

Just wanted to add in here that I would like to see some time put into making this work.

I understand why it is not currently implemented.

However, it seems to me that at the point where decidePolicyForNavigationAction is executing, the WebKit process is waiting anyway so getting the process to do a slow copy of some data should not be an issue - could there be a way to have the WKWebView instance get the HTTPBody (presumably requesting it over IPC) then, only if requested. Or does the IPC not work that way?

I have also filed this as rdar://24489009

Comment 33 Sam Sneddon [:gsnedders] 2022-02-01 02:55:08 PST

<rdar://18399639>

(In reply to David from comment #3)
> Just wanted to add in here that I would like to see some time put into
> making this work.
> 
> I understand why it is not currently implemented.
> 
> However, it seems to me that at the point where
> decidePolicyForNavigationAction is executing, the WebKit process is waiting
> anyway so getting the process to do a slow copy of some data should not be
> an issue - could there be a way to have the WKWebView instance get the
> HTTPBody (presumably requesting it over IPC) then, only if requested. Or
> does the IPC not work that way?
> 
> I have also filed this as rdar://24489009

That was resolved as bug 179077.

Comment 34 Radar WebKit Bug Importer 2022-02-01 02:55:21 PST

<rdar://problem/88319632>