5

Background:

My PHP code handles typical HTTP HEAD requests by sending either an HTTP status 404 response or a 204 response. This seems correct to me, since RFC7231 specifies HTTP status 204 as:

6.3.5. 204 No Content

The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied...

The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any)...

A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body...

https://www.rfc-editor.org/rfc/rfc7231#section-6.3.5

Since the user agent is only requesting the headers and not the file itself, 204 seems to fit.

Surprise #1:

When an <object> element has a URL for the data attribute, MSIE/Edge initially makes an HTTP HEAD request in order to determine the content-type via the response headers. While another MS quirk, it makes sense, as it allows the browser to pre-load the needed handlers in advance of receiving the content. When it receives a suitable response to the HEAD request, it will then make an HTTP GET request for the file itself.

Now, this wouldn't have been so much of an issue if it weren't for...

Surprise #2:

When MSIE/Edge receives a 204 response to its HEAD request, it treats it as an error and aborts loading the file.

This was, needless to say, quite frustrating to discover (the process and the discovery itself).

Have I misunderstood the purpose or usage of the 204 response? I know industry-usage often diverges from specifications, but this seems... wrong.

 let input: [String: [String: [String: Any]]] = ["posts":
    [
        "randonRootKey1": [
            "randomChildKey1": [:],
        ],
        "randonRootKey2": [
            "randomChildKey2": [:],
            "randomChildKey3": [:],
        ]
    ]
]

var output = [String: Any]()

for dictionary in input["posts"]!.values {
    for (key, value) in dictionary {
        output[key] = value
    }
}

print(output)

["randomChildKey3": [:], "randomChildKey2": [:], "randomChildKey1": [:]]

4

2 に答える 2

5

HEAD で 204 を返す場合、GET を実行すると 204 も取得するため、取得するコンテンツがないことをユーザー エージェントに伝えています。ユーザー エージェントの観点からは、HEAD が利用可能なすべての情報を取得したため、GET を実行しても意味がありません。

GET リクエストを実行すると 200 が返される場合、HEAD も 200 を返す必要があります。

于 2016-08-16T03:36:05.833 に答える
2

私は Edge チームのエンジニアであり、あなたが言及している問題を確認しています。とりあえず、ヘッダーを送信するだけの場合でも (かなり一般的です)、200 OK 応答を使用することをお勧めします。

2 つのリクエストが標準から外れていること、および 204 が後続の GET リクエストを妨げてはならないことに同意します。

この問題をより徹底的に評価するために、チームにバグを報告しました。

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8499759/

于 2016-08-16T01:04:12.633 に答える