我应该使用HTTP 4xx来指示HTML表单错误吗？ [英] Should I use HTTP 4xx to indicate HTML form errors?

问题描述

我花了20分钟调试一些（django）单元测试。我正在测试一个视图POST，我期待一个302返回代码，之后我声称一堆数据库实体是按预期的。原来最近合并的提交添加了一个新的表单字段，我的测试失败了，因为我没有包含正确的表单数据。

I just spent 20 minutes debugging some (django) unit tests. I was testing a view POST, and I was expecting a 302 return code, after which I asserted a bunch database entities were as expected. Turns out a recently merged commit had added a new form field, and my tests were failing because I wasn't including the correct form data.

问题在于测试失败了，因为HTTP返回代码是200而不是302，我只能通过打印响应HTTP并查看它来解决问题。除了必须通过HTML来解决问题的烦恼之外，对于没有得到处理的POST来说，200似乎是错误的代码。 4xx（客户端错误）似乎更合适。此外，它会使测试变得简单，因为响应代码会直接指出我的问题。

The problem is that the tests were failing because the HTTP return code was 200, not 302, and I could only work out the problem by printing out the response HTTP and looking through it. Aside from the irritation of having to look through HTML to work out the problem, a 200 seems like the wrong code for a POST that doesn't get processed. A 4xx (client error) seems more appropriate. In addition, it would have made debugging the test a cinch, as the response code would have pointed me straight at the problem.

我读过关于使用422（不可处理的）实体）作为REST API中可能的返回代码，但找不到在HTML视图/处理程序中使用它的任何证据。

I've read about using 422 (Unprocessable Entity) as a possible return code within REST APIs, but can't find any evidence of using it within HTML views / handlers.

我的问题是 - 是否还有其他人在做什么这个，如果没有，为什么不呢？

My question is - is anyone else doing this, and if not, why not?

[ UPDATE 1 ]

只是为了澄清，这个问题与HTML表单有关，而不是API。

Just to clarify, this question relates to HTML forms, and not an API.

这也是关于HTTP响应代码本身的问题 - 而不是Django。这恰好就是我正在使用的东西。我删除了django标签。

It is also a question about HTTP response codes per se - not Django. That just happens to be what I'm using. I have removed the django tag.

[ UPDATE 2 ]

进一步澄清，W3C参考（ http://www.w3.org/Protocols/rfc2616/rfc2616-sec10。 html ）：

Some further clarification, with W3C references (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):

10.2成功2xx

此类状态代码表示客户的请求已成功接收，理解和接受。

This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.4客户端错误4xx

4xx类状态代码适用于客户端似乎有错误的情况。

The 4xx class of status code is intended for cases in which the client seems to have erred.

10.4.1 400错误请求

由于语法格式错误，服务器无法理解请求。

The request could not be understood by the server due to malformed syntax.

来自 https://tools.ietf.org/html / rfc4918＃page-78

11.2。 422无法处理的实体

11.2. 422 Unprocessable Entity

422（不可处理的实体）状态代码表示服务器
了解请求实体的内容类型（因此
415（不支持的媒体类型）状态代码是不合适的），并且请求实体的
语法是正确的（因此400（错误请求）
状态代码是不合适的）但是无法处理包含的
指令。例如，如果XML
请求主体包含格式正确（即语法正确），但语义错误的XML指令
，则可能会出现此错误情况。

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

[更新3 ]

深入研究，422是WebDAV扩展[1] ]，这可能解释其默默无闻。也就是说，由于Twitter为了自己的目的使用420，我想我会满足于我想要的任何东西。但它将从4开始。

Digging in to it, 422 is a WebDAV extension[1], which may explain its obscurity. That said, since Twitter use 420 for their own purposes, I think I'll just whatever I want. But it will begin with a 4.

[ UPDATE 4 ]

备注关于自定义响应代码的使用，以及如何处理它们（如果无法识别），来自HTTP 1.1规范（） http://tools.ietf.org/html/rfc2616#section-6.1.1 ）：

Notes on the use of custom response codes, and how they should be treated (if unrecognised), from HTTP 1.1 specification (http://tools.ietf.org/html/rfc2616#section-6.1.1):

HTTP状态代码是可扩展的。 HTTP应用程序不需要
来理解所有已注册状态代码的含义，尽管这种
理解显然是可取的。但是，应用程序必须
了解任何状态代码的类，如第一个
数字所示，并将任何无法识别的响应视为等同于该类的
x00状态代码，例外情况是，
无法识别的响应不得缓存。例如，如果客户端收到
无法识别的状态代码431，则可以
安全地假设其请求有问题，并且
将响应视为已收到400状态代码。在这样的
情况下，用户代理应该向用户呈现实体返回
的响应，因为该实体可能包含human-
可读信息，这将解释异常状态。

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.

[1] https：// tools。 ietf.org/html/rfc4918

推荐答案

如果结果不成功，你说200是错的。

You are right that 200 is wrong if the outcome is not success.

我还认为成功 - 重定向到结果页面应该是303，而不是302.

I'd also argue that a success-with-redirect-to-result-page should be 303, not 302.

4xx对于客户端错误是正确的。 422对我来说似乎是对的。在任何情况下，如果没有通过IANA注册，请不要发明新的4xx代码。

4xx is correct for client error. 422 seems right to me. In any case, don't invent new 4xx codes without registering them through IANA.

这篇关于我应该使用HTTP 4xx来指示HTML表单错误吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！