Http 204 loads blank page on all iOS Browsers - Safari, Chrome, iOS (Amazon S3 related)

I built a web app that allows a user to upload files to an Amazon s3 bucket via a webform, I unfortualy am in a sandboxed evnoronment and cannout make a JS httprequest to s3. Anyway, Amazon send a 204 response back if the PUT was a success, unless you specify it to respond with a 201. I've searched exhaustivly around the net and have found mutple older stackoverflow topics and similar sites refering to this same issue with Amazon S3 or with 204 responsess in general, on iOS. I have tested the app on multipel Android devices, in Chrome as well as all major desktop clients and it works as expected.


In iOS based browsers, it returns a blank page, which is what a 204 is but that is not what the HTTP 1.1 Specs say a 204 shoudl do on a client. Can anyone help me fix this? Suggest a solution or a direction to look? What I can offer are these things :


Amazon's documentation of POST responses :


The status code returned to the client upon successful upload if

success_action_redirect
is not specified.

Accepts the values 200, 201, or 204 (default).

If the value is set to 200 or 204, Amazon S3 returns an empty document with a 200 or 204 status code.

If the value is set to 201, Amazon S3 returns an XML document with a 201 status code.

If the value is not set or if it is set to an invalid value, Amazon S3 returns an empty document with a 204 status code.

Type: String

Default: None

Note

Some versions of the Adobe Flash player do not properly handle HTTP responses with an empty body. To support uploads through Adobe Flash, we recommend setting

success_action_status
to 201.

The HTTP 1.1 Spec for a 204 response via the W3C :


The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.


Here is a nice little tool for testing responses :

http://httpstat.us/

Clicking the 204 link should cause your browser to load for a second and then the page not do anything. This works as expected in all browsers, except ones running on iOS. My devices are at version 10.2.


Again, I am at the mercy of Safari (the Client), this is a simple form POST that recieves a 204 response, I can not catch the response and rely on the client to handle it correclty, which it appears to not do. Thank you for your help

Replies

kidniki100 is right - the way iOS handles 204 responses is incorrect.


I ran into this exact problem in my experience using the HubSpot marketing automation software. HubSpot's embedded forms require a 204 header to submit properly without causing a page refresh - this makes for terrible UX on handhelds - where UX and percieved speed is critically important.


Are there any plans to deal with this sooner rather than later?


Also - kidniki100 I am noticing this issue in MS Edge as well. Not sure if you can verify.

I run into the same problem.

Is this problem solved now? Has anybody an explanation?

Thank's in advanced.

https://stackoverflow.com/questions/51351482/a-http-204-response-returns-a-blank-page-in-ios-is-there-a-way-to-stop-this


"it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view"

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


Happy 2019! The bug is still there.

Happy 2021! The bug is still there.

I've built a led-matrix frame. I had to solve all sorts of power, 3d printing, hardware, software issues. I made a simple html page to control the frame. Everything was working as expected .. until I opened the page on my ios devices. I can't believe I've managed to solve everything that was supposed to NOT work, and now I need to spend resources on something that IS supposed to work, but which Apple decided to make NOT work for whatever reason.

Dear Apple, RFCs are there for a reason. RFCs were invented before you existed. They define standards. They define how our Internet works. They power YOUR devices. You can't just wake up and decide to mess with them. It's not wise. It's not fair. It's not a good business decision.

Please make all your platforms honour the way an http 204 return code should be handled NOW.

Thanks best regards

I have just stumbled across this same problem. Does Apple have any plans to make its browsers compliant with the standards? The way they respond to an http response 204 is not correct.