在“验证”中正确使用 HTTP 状态代码 服务器
我的应用程序发送到第三方 SOA 服务器的数据中有复杂的 XML。 服务器所有者确实提供了 XML 架构 (.xsd)，并且由于服务器会拒绝带有无意义消息的无效 XML，因此我需要在发送之前在本地验证它们。
我可以使用独立的 XML 模式验证器，但它们速度很慢，主要是因为解析模式文件需要时间。 因此，我以 HTTP 服务器的形式编写了自己的模式验证器（如果重要的话，用 Java 编写），该服务器缓存已解析的模式。
问题是：在验证过程中很多事情都可能出错。 除了意外异常和成功验证之外：
- 服务器可能找不到指定的架构文件
- 指定的文件可能不是有效的架构文件
- XML对于架构文件无效
因为它是HTTP服务器我想为客户端提供有意义的状态代码。 对于上述所有情况，服务器是否应该回答 400 错误（错误请求）？ 或者它们与 HTTP 无关，它应该在正文中回复 200 消息？ 还有其他建议吗？
更新：主应用程序是用Ruby编写的，它没有良好的xml模式验证库，因此单独的验证服务器并没有过度设计。
Among the data my application sends to a third-party SOA server are complex XMLs. The server owner does provide the XML schemas (.xsd) and, since the server rejects invalid XMLs with a meaningless message, I need to validate them locally before sending.
I could use a stand-alone XML schema validator but they are slow, mainly because of the time required to parse the schema files. So I wrote my own schema validator (in Java, if that matters) in the form of an HTTP Server which caches the already parsed schemas.
The problem is: many things can go wrong in the course of the validation process. Other than unexpected exceptions and successful validation:
- the server may not find the schema file specified
- the file specified may not be a valid schema file
- the XML is invalid against the schema file
Since it's an HTTP Server I'd like to provide the client with meaningful status codes. Should the server answer with a 400 error (Bad request) for all the above cases? Or they have nothing to do with HTTP and it should answer 200 with a message in the body? Any other suggestion?
Update: the main application is written in Ruby, which doesn't have a good xml schema validation library, so a separate validation server is not over-engineering.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
状态代码 422（“无法处理的实体”） 听起来足够接近：
“422（不可处理的实体）状态代码意味着服务器理解请求实体的内容类型（因此 415（不支持的媒体类型）状态代码是不合适的），并且请求实体的语法是正确的（因此 400（错误）请求）状态代码不合适）但无法处理所包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现此错误情况。”
Status code 422 ("Unprocessable Entity") sounds close enough:
"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."
将验证过程中的错误情况映射到有意义的 HTTP 状态代码是一个完全有效的想法。
我假设您使用 URI 将 XML 文件作为 POST 内容发送到验证服务器，以确定用于验证的特定架构。
因此，这里有一些错误映射的建议：
It's a perfectly valid thinking to map error situations in the validation process to meaningful HTTP status codes.
I suppose you send the XML file to your validation server as a POST content using the URI to determine a specific schema for validation.
So here are some suggestions for error mappings:
假设您要将 XML 文件发布到资源，例如：
POST /validator
内容类型：application/xml
如果请求实体无法解析其提交的媒体类型（即 application/xml），则 400 Bad Request 是正确的状态。
如果它在语法上解析为它提交的媒体类型，但它没有根据某些所需的模式进行验证，或者具有使其无法被提交到的资源处理的语义 - 那么 422 Unprocessable Entity 是最好的状态（尽管您可能应该在错误响应中伴随一些更具体的错误信息；还要注意，它在技术上是在 HTTP、WebDAV 的扩展中定义的，尽管它在 HTTP API 中使用相当广泛，并且在出现错误时比任何其他 HTTP 错误状态更合适。提交的实体存在语义错误）。
如果它作为媒体类型提交，这意味着 xml 之上有一个特定的模式（例如 application/xhtml+xml），那么如果它无法根据该模式进行验证，您可以使用 400 Bad Request。 但是，如果它的媒体类型是纯 XML，那么我认为该模式不是媒体类型的一部分，尽管它有点灰色区域； 如果 xml 文件指定了其架构，您可能会将验证解释为 application/xml 语法要求的一部分。
如果您通过 multipart/form 或 application/x-www-form-urlencoded 表单提交来提交 XML 文件，那么您必须使用 422 Unprocessable Entity 来解决 XML 文件的所有问题； 仅当基本表单上传存在语法问题时，400 才适用。
Say you're posting XML files to a resource, eg like so:
POST /validator
Content-type: application/xml
If the request entity fails to parse as the media type it was submitted as (ie as application/xml), 400 Bad Request is the right status.
If it parses syntactically as the media type it was submitted as, but it doesn't validate against some desired schema, or otherwise has semantics which make it unprocessable by the resource it's submitted to - then 422 Unprocessable Entity is the best status (although you should probably accompany it by some more specific error information in the error response; also note it's technically defined in an extension to HTTP, WebDAV, although is quite widely used in HTTP APIs and more appropriate than any of the other HTTP error statuses when there's a semantic error with a submitted entity).
If it's being submitted as a media type which implies a particular schema on top of xml (eg as application/xhtml+xml) then you can use 400 Bad Request if it fails to validate against that schema. But if its media type is plain XML then I'd argue that the schema isn't part of the media type, although it's a bit of a grey area; if the xml file specifies its schema you could maybe interpret validation as being part of the syntactic requirements for application/xml.
If you're submitting the XML files via a multipart/form or application/x-www-form-urlencoded form submissions, then you'd have to use 422 Unprocessable Entity for all problems with the XML file; 400 would only be appropriate if there's a syntactic problem with the basic form upload.
Amazon 可以用作如何将 http 状态代码映射到实际应用程序级别条件的模型：
http://docs.amazonwebservices.com/AWSImportExport/latest/API /index.html?Errors.html（请参阅 Amazon S3 状态代码标题）
Amazon could be used as a model for how to map http status codes to real application level conditions:
http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html (see Amazon S3 Status Codes heading)
来自 w3c：
400 = 由于语法错误，服务器无法理解该请求。
除非服务器实际上无法理解请求，否则我不会提供该服务。 如果您刚刚收到无效的 xml，请拨打 200 并解释为什么事情不起作用。
问候
伪造的
From w3c:
400 = The request could not be understood by the server due to malformed syntax.
I wouldn't serve that up unless it was actually the case that the server could not understand the request. If you're just getting invalid xml, serve a 200 and explain why things are not working.
Regards
Fake
我会选择
400 Bad request和正文中更具体的消息（可能在标头中包含辅助错误代码，例如X-Parse-Error: 10451更容易加工）I'd go with
400 Bad requestand a more specific message in the body (possibly with a secondary error code in a header, likeX-Parse-Error: 10451for easier processing)这听起来是个好主意，但 HTTP 状态代码并没有真正提供“操作失败”的情况。 我将返回带有
X-Validation-Result: true/false标头的 HTTP 200，并根据需要将正文用于任何文本或“原因”。 将 HTTP 4xx 保存为 HTTP 级别错误，而不是应用程序级别错误。但这是一种耻辱和双重标准。 许多应用程序使用 HTTP 身份验证，并且它们能够从应用程序级别返回 HTTP 401 Not Authorized 或 403 Forbidden。 如果您可以使用某种类型的“全面 HTTP 4xx 请求拒绝”，这将是方便且明智的。
That sounds like a neat idea, but the HTTP status codes don't really provide an "operation failed" case. I would return HTTP 200 with an
X-Validation-Result: true/falseheader, using the body for any text or "reason" as necessary. Save the HTTP 4xx for HTTP-level errors, not application-level errors.It's kind of a shame and a double-standard, though. Many applications use HTTP authentication, and they're able to return HTTP 401 Not Authorized or 403 Forbidden from the application level. It would be convenient and sensible to have some sort of blanket HTTP 4xx Request Rejected that you could use.