Bug 60206 – Proper handling of HTTP 204 (No Content) status code

• Component: WebKit Misc.
• Status: REOPENED

[Luiz Agostini]

from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.5:

10.2.5 204 No Content

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.

[Alexey Proskuryakov]

Could you please clarify what exactly is the bug to fix here? This report doesn't seem actionable in its current state.

[Luiz Agostini]

(In reply to comment #1)
> Could you please clarify what exactly is the bug to fix here? This report doesn't seem actionable in its current state.

Responses containing HTTP code 204 should be ignored by the browser and the view should not be updated.


I made it for Qt and added a test for it. The new test is http/tests/navigation/response204.html.

Some platforms (Mac, Win and GTK) fail on this new test. But it seems that if this test fail in Mac or Win then hundreds of other tests fail as well. See https://bugs.webkit.org/show_bug.cgi?id=42529#c21

The test was skipped in those platforms by r85784.

[Alexey Proskuryakov]

Here is how I tested:
1. Opened http://www.apple.com in Safari 5.0.5 (also tested with ToT).
2. Once that finished loading, changed address in address bar to <http://127.0.0.1:8000/navigation/resources/response204.pl>, and hit Enter.

Results: The address reverted to http://www.apple.com, page content was not affected.

This looks like expected behavior. I haven't investigated what's going on in the test, but there are no known issues with 204 responses (we track bug 4858 here, but it's not really about 204, it's about stopping timers too early on any load).

[Luiz Agostini]

(In reply to comment #3)
> Here is how I tested:
> 1. Opened http://www.apple.com in Safari 5.0.5 (also tested with ToT).
> 2. Once that finished loading, changed address in address bar to <http://127.0.0.1:8000/navigation/resources/response204.pl>, and hit Enter.
> 
> Results: The address reverted to http://www.apple.com, page content was not affected.

Good. I was expecting this test to fail in some platforms but it seems that Mac is ok with this 204 handling.

> 
> This looks like expected behavior. I haven't investigated what's going on in the test, but there are no known issues with 204 responses (we track bug 4858 here, but it's not really about 204, it's about stopping timers too early on any load).

Yeah, it may be then that I did not provide the proper test. 

The response204.is very simple, I will copy it here:

    <script>
        if (window.layoutTestController) {
            layoutTestController.dumpAsText();
            layoutTestController.dumpBackForwardList();
            layoutTestController.queueLoad("resources/response204.pl");
        }
    </script>

And this is the result that I was expecting:

    ============== Back Forward List ==============
    curr->  http://127.0.0.1:8000/navigation/response204.html  **nav target**
    ===============================================

Meaning that the response from resources/response204.pl was ignored.

But it was not the result for SnowLeopard as you can see here http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20%28Tests%29/r85783%20%2828972%29/http/tests/navigation/response204-diffs.txt :

    --- /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release-tests/build/layout-test-results/http/tests/navigation/response204-expected.txt	2011-05-04 13:57:57.000000000 -0700
    +++ /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release-tests/build/layout-test-results/http/tests/navigation/response204-actual.txt	2011-05-04 13:57:57.000000000 -0700
    @@ -1,5 +1,6 @@
 
 
     ============== Back Forward List ==============
    -curr->  http://127.0.0.1:8000/navigation/response204.html  **nav target**
    +        http://127.0.0.1:8000/navigation/response204.html  **nav target**
    +curr->  http://127.0.0.1:8000/navigation/resources/response204.pl  **nav target**
     ===============================================

Nor for Leopard as you can see here http://build.webkit.org/results/Leopard%20Intel%20Release%20%28Tests%29/r85783%20%2831877%29/http/tests/navigation/response204-diffs.txt :

    --- /Volumes/Big/WebKit-BuildSlave/leopard-intel-release-tests/build/layout-test-results/http/tests/navigation/response204-expected.txt	2011-05-04 13:47:14.000000000 -0700
    +++ /Volumes/Big/WebKit-BuildSlave/leopard-intel-release-tests/build/layout-test-results/http/tests/navigation/response204-actual.txt	2011-05-04 13:47:14.000000000 -0700
    @@ -1,5 +1,6 @@
 
 
     ============== Back Forward List ==============
    -curr->  http://127.0.0.1:8000/navigation/response204.html  **nav target**
    +        http://127.0.0.1:8000/navigation/response204.html  **nav target**
    +curr->  http://127.0.0.1:8000/navigation/resources/response204.pl  **nav target**
     ===============================================

Is that test wrong?

[Luiz Agostini]

BTW, I have tried the test in bug 4858 and did not reproduce the problem in safari 5.0.5 or in chromium 11.0.696.57 or QtTestBrowser r85857. :)

[Alexey Proskuryakov]

I see. Turns out that Safari handles the policy for 204, not WebKit. I think that it should be implemented in WebCore.

Seems strange that the test doesn't just use waitUntilDone/window.location="...", but there probably was a reason to use queued load machinery.

Thanks for testing bug 4858! I'm surprised that it no longer fails, but it's great news.

[John Sullivan]

Safari does currently handle that code directly, but it seems fine to me to handle it in WebKit instead (Darin said the same thing once too).

[Luiz Agostini]

The other question is why so many tests failed after running this test. It seems that if http/tests/navigation/response204.html fails then hundreds of other tests fail as well.

https://bugs.webkit.org/show_bug.cgi?id=42529#c21
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20%28Tests%29/r85783%20%2828972%29/results.html
http://build.webkit.org/results/Leopard%20Intel%20Release%20%28Tests%29/r85783%20%2831877%29/results.html

[Martin Robinson]

*** This bug has been marked as a duplicate of bug 104865 ***

[Martin Robinson]

Going to reverse the duplication graph here.

[Martin Robinson]

*** Bug 104865 has been marked as a duplicate of this bug. ***

[Martin Robinson]

Created attachment 180810 [details]
Patch

[Alexey Proskuryakov]

As mentioned in duplicate, this change looks good to me, but someone who worked on loader code more recently should review.

[Anders Carlsson]

Comment on attachment 180810 [details]
Patch

Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.

[Alexey Proskuryakov]

rdar://problem/21864977

[Gordon Murray]

This issue is still reproducable on iOS 10.

The easiest way to reproduce is via the site: http://httpstat.us/

When you click the link "204 No Content" on a desktop browser it is handled correctly the browser does nothing to view as per HTTP spec.

On iOS the view is changed.

[Tommy Vogt]

Does this patch work?  In iOS 10, this is a huge issue and can easily be reproduced while using an Amazon s3 Form post.  In every other browser, Chrome on android and all Desktop browsers, the current page view is kept when a 204 response is recieved.  In both Chrome for iOS and Safari iOS, it redirects to a blank page, which it should not.  Do we have to wait for Apple to update for this to work?

[Gordon Murray]

Have raised separate Bug 166633 - iOS browsers not correctly handling HTTP 204 response to flag the iOS handling issue.

[Alexey Proskuryakov]

*** Bug 166633 has been marked as a duplicate of this bug. ***

[Tommy Vogt]

I don't think this is a Webkit bug.  Firefox on iOS has the exact same issue and it is Gecko based.  This is an Apple bug it seems.  I don't know what the browsers get from the OS but it seems to be telling them to actually render a blank page.  I've tested this in every iOS browser and the same thing occurs, a blank page gets loaded.

[Darin Adler]

Comment on attachment 180810 [details]
Patch

Patch looks good to me too. Someone should apply this and test to see if this change fixes things in Safari on iOS (could also try other WebKit-based iOS browsers such as Chrome and Firefox).

[Gordon Murray]

(In reply to comment #20)
> I don't think this is a Webkit bug.  Firefox on iOS has the exact same issue
> and it is Gecko based.  This is an Apple bug it seems.  I don't know what
> the browsers get from the OS but it seems to be telling them to actually
> render a blank page.  I've tested this in every iOS browser and the same
> thing occurs, a blank page gets loaded.
All web browsers on iOS are WebKit based including Firefox which would normally be based on Gecko.

Is this issue going to be resolved?

It is an obvious violation of the HTTP standard and inconsistent with all on other platforms, so it should be resolved.

[Rob Buis]

Pull request: https://github.com/WebKit/WebKit/pull/34059

[EWS]

Committed 284550@main (61909d6ad7cf): <https://commits.webkit.org/284550@main>

Reviewed commits have been landed. Closing PR #34059 and removing active labels.

[Ahmad Saleem]

Reverted in https://commits.webkit.org/285577@main

https://github.com/WebKit/WebKit/commit/4eac02f13b2fbe5ee3ea4851b0e2c2883329206f

[Alex Christensen]

rdar://138793770 now tracks fixing this internally.  Can we do it without changing the value of WKNavigationResponse.canShowMIMEType?