我正在使用 SP2010 客户端对象模型上传到文档库，遵循 Microsoft 此处的指示：http: //msdn.microsoft.com/en-us/library/ee956524.aspx#SP2010ClientOMOpenXml_Uploading

执行以下代码时，我面临 HTTP 409（冲突）状态代码。

我究竟做错了什么？

有时（当资源被请求太频繁时）我会拦截带有验证码的（HTML）资源的呈现。拦截不会产生任何重定向。它发生在同一个 URI 上。

我现在想知道哪种 HTTP 状态代码最适合这些要求：

• 它应该符合语义。

• Google 应该明白，这种拦截是一种临时情况，不应影响其索引中的现有资源。

• Web 浏览器将显示带有验证码的响应正文。

这些是我迄今为止确定的候选人：

409 冲突

由于与资源的当前状态冲突，无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息让用户识别冲突的来源。

这听起来很完美。冲突状态来自那些过于频繁地请求资源的客户端。响应还包括足够的信息来识别冲突的来源并解决它。

503服务不可用

由于服务器临时过载 […]，服务器当前无法处理请求。这意味着这是一种暂时的情况[…]。如果已知，延迟的长度可以在 Retry-After 标头中指示。

这听起来适中。我什至可能知道延迟的长度并提供这样的标题。但是我在这里错过了用户可以解决问题的观点。此外，范围太广（重载的服务器与重载的资源）。

我正在尝试使用 angularjs 作为前端并使用 express js 构建一个应用程序。我使用 yeoman 构建了这两个项目，我的 angular 应用程序在 localhost:9000 上运行，我的 express 应用程序在 localhost:3000 上运行。当我尝试从 Angular 与 Express js 应用程序交谈时，我收到了一个跨域请求，有没有办法解决这个问题。

Express App 中的 app.js

angularjs 应用程序中的 app.js

错误

编辑

这是我添加到 app.js 文件中的代码：

这也会引发与以前相同的错误（“请求的资源上不存在‘Access-Control-Allow-Origin’标头。”）。

编辑

使用后

这是抛出 POST localhost:3000/signup 409 （冲突）

While working on an (json) REST API, I came upon the situation that we have a representation of a user resource where I wanted to prevent a field (email) to be overridden within a PUT. If I understand correctly, then a PUT should contain the entire representation of the resource to replace the old one.

So for example, when fetching a user from the API (Some headers left out for simplicity):

And you'd want to fix the typo in John Smiths name, you'd do:

Now, if someone were to put a different e-mail address, am I allowed to use a 409 to indicate the request was not processed?

According to https://www.rfc-editor.org/rfc/rfc2616

• A 400 Bad Request indicates malformed syntax (which this isn't)
• A 403 Forbidden could be used, but it seems to me that it is more about access to the entire resource, not part of it
• A 409 Conflict seems to be about a technical reason for not being able to fulfil the request, and not about having privileges to do something.

So, my question is: which status code should I use?

Edit: in light of the accepted answer; the response would become

我有一个应用程序封装了与 TFS REST API 的交互，以便对构建进行排队。该应用程序只是将所需的 json 发送到 API，它工作了几个月，直到它突然开始返回 409 - 冲突。

System.Net.WebException：远程服务器返回错误：（409）冲突。( https://tfs2015/tfs/spf/SPF/_apis/build/builds?api-version=2.0 :{"definition":{"id":190},"parameters":"{}"})

w3.org 将 http 代码 409 定义为：

由于与资源的当前状态冲突，无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息让用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题；但是，这可能是不可能的，也不是必需的。

409 也不会消失 - 简单的重试始终失败。即使是重新启动构建服务器的整个“您是否尝试过重新打开它”的方法也无济于事。

问题是当我尝试构建 gradle 时，它​​会抛出：

我已经尝试通过https://github.com/square/okhttp下载 JAR ，而不是通过 url 编译，但是没有用，我的想法已经用完了，所以如果有人可以帮助我，我会很高兴

项目等级：

模块：应用程序等级：

我正在使用 mod security 来查找 post 参数中的特定值，并在出现重复时阻止请求。我正在使用 mod security 用户集合来做到这一点。问题是我的请求运行时间很长，因此单个请求可能需要 5 分钟以上。我假设的用户集合在第一个请求得到处理之前不会被写入磁盘。如果在执行第一个请求期间，另一个请求使用 post 参数的重复值进入，则第二个请求不会被阻止，因为该集合尚不可用。我需要避免这种情况。我可以在 mod 安全性中跨请求使用基于内存的共享集合吗？还有什么办法吗？片段如下：

从HTTP 状态代码列表（维基百科）它说：

409 冲突

表示由于请求中的冲突而无法处理请求，例如多个同时更新之间的编辑冲突。

和

需要 428 前提条件 (RFC 6585)

源服务器要求请求是有条件的。旨在防止“丢失更新”问题，即客户端获取资源的状态，对其进行修改，然后将其放回服务器，同时第三方已修改服务器上的状态，从而导致冲突。”

但是， 428项中提到的“丢失更新”问题不正是409项中提到的“编辑冲突”问题吗？

所以问题是这两个状态码有什么区别，我们什么时候应该使用它们中的哪一个？

即使在阅读了许多文档、书籍、规范之后， 我也不能 100% 确定在我的情况下我应该使用 http 状态代码 403 还是 409。

有人认为 403 应该只用于授权问题，但是看到twitter 的 api使用 403 来违反更新限制，我认为 403 的实际使用不仅仅是授权问题。也许它可以用来告诉请求违反了服务器端约束。

而且，从规范来看，当我们可以预期客户端可以解决问题时，似乎使用了 409。

我很欣赏一些现实世界中何时使用 403 和何时使用 409 的示例，以及关于在我的案例中使用哪些代码的意见，我将在下面的摘要中列出（以免违反 NDA ）。

编辑后：这个例子很长，但简单地说，它是关于当约束验证失败时返回什么代码。当约束验证失败时，你总是返回 400 吗？我应该返回 400 而不是 403 或 409？

有一个客户端告诉服务 A 哪个书架包含特定的书。在向数据库记录哪本书在哪个书架上时，服务 A 能够告诉客户客户正试图将书放在错误的书架上。服务 A 可以通过询问另一个服务 B 来判断这一点，该服务 B 在决定一本书应该去哪里时基本上有一些逻辑。

在这种情况下，服务 A 应该使用什么 http 代码？

（请求与服务 B 的决定冲突 - 409？ - 但客户端无法解决此问题，因为当服务 B 做出决定时，它是永久性的。并且书 id 和书架 id 都在路径参数中（即，它们是此端点中的唯一参数），因此客户端无法真正进行任何更改来解决相同请求的问题）

此外，客户端能够告诉服务 A 不应再使用书架（因为它已满或出于任何原因）。当客户端告诉服务 A 书架 C 不再使用时，然后客户端告诉服务 A 它想在书架 C 上放另一本书，服务 A 应该告诉客户端它不能这样做。在这种情况下，服务 A 应该使用什么 http 代码？（该请求会与说书架 C 未使用的数据库状态冲突 - 409？但客户端无法解决此问题，因为当书架未使用时，它在服务 A 中是永久的，并且从不使用再次——不是409？）

提前感谢您的时间和投入！

我可以理解 409 意味着在添加事件的情况下重复输入。但是当我们试图删除一个事件时它意味着什么？如果该事件已被删除，我将收到 410(Gone)，我完全理解这一点。我正在使用适用于 Android 的 Google 日历 API。