You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any POST request coming from SWWebView doesn't have its HTTP body attached. Right now I have a very horrible patch on fetch that inserts the (string) body as a header before performing the fetch. The native code repatches this to be the actual body so no backend code ever needs to be aware of this, but there are still a lot of issues:
It only works with strings.
Presumably there is a character limit eventually.
It doesn't cover POST page requests, and I don't know how it could.
There are some stopgap fixes we could implement:
base64 encoding (to allow non-strings)
sending the body though the JS API, returning a unique ID, then sending that in the header (to get around character limits)
But they're all pretty awful. Unfortunately the only real fix I can see is Apple fixing the original bug, but depending on how long that takes, we might need to implement some stopgaps. In the more immediate term, we could get some tests going to see what these character limits actually are.
I've opened a bug for this: http://www.openradar.me/radar?id=4952053319204864 but so far no replies.
Any POST request coming from SWWebView doesn't have its HTTP body attached. Right now I have a very horrible patch on
fetchthat inserts the (string) body as a header before performing the fetch. The native code repatches this to be the actual body so no backend code ever needs to be aware of this, but there are still a lot of issues:There are some stopgap fixes we could implement:
But they're all pretty awful. Unfortunately the only real fix I can see is Apple fixing the original bug, but depending on how long that takes, we might need to implement some stopgaps. In the more immediate term, we could get some tests going to see what these character limits actually are.