问题标签 [http-status-codes]

我已经阅读了几篇关于不同 HTTP 重定向状态代码优点的文档，但这些文档都非常以 SEO 为中心。我现在遇到了一个搜索引擎不考虑的问题，因为相关网站的部分不公开可见。

但是，我们确实希望我们的网站尽可能准确/有用地处理元数据，尤其是出于可访问性的原因。

现在，我们的应用程序获取第三方提供的外部链接，并将它们路由到带有免责声明的反欺骗页面。由于此重定向页面也可以通过 Ajax 调用有效地嵌入某些星座中，因此我们还希望从引用者中剥离任何查询参数（出于隐私目的；目标站点无权查找用户之前访问的内部页面） .

为此，确认按钮会触发一个服务器端脚本，该脚本反过来会重定向（而不仅仅是为用户打开页面）。

至于为什么我们的反欺骗免责声明页面最终会触发重定向。

问题是：

我使用哪个状态码有什么不同吗？非典型浏览器（例如屏幕阅读器）是否在乎？如果是这样，这种重定向的最佳做法是什么？语义上最合理的，如果你愿意的话？在我看来，他们都有不同程度的不真诚。

我正在考虑 302 - 但由于尝试为页面添加书签是没有意义的（它受 crsf 令牌保护），所以 301 也可能没有害处，是吗？所以我想知道是否有理由让我更喜欢一个。

我们正在使用在 GWT 中制作的应用程序，服务器为 tomcat。该项目运行正常，但是存在重新启动服务器的情况。此时，下面代码的ajax调用返回空白文本，状态码为304

通常我们会在这个响应文本中从服务器取回一些数据。当响应本身为空白时，我们现在如何获取数据？

我在 global.asx 的 Application_Error 子中查找 HttpExceptions

我可以单步执行此代码并确认它确实命中了 Server.Transfer("error_404.aspx") 以及 error_404.aspx 的 Page_Load，但它显示的只是一个空白页面。

我有一个网站，主要显示内容的分页列表（文章、数据元素等），我想知道当用户在可用列表范围之外导航时返回 HTTP 404（例如，通过手动编辑的 url）。

有些网站只显示“没有结果/页码超出范围”，有些网站还额外返回 HTTP 404 状态。

你对此有何看法，为什么？

更新

它不是和 api 响应。这个问题是关于用户查看的页面，其中包括在主要区域中显示列表/表格。

更新

边界示例：第 1 页是超出范围的页面，因为显示列表的数据尚不存在。

我应该显示 404 吗？如果它在哪里搜索结果我不会介意......但是对于分页列表/数据表的普通查看似乎很苛刻。

示例： Stack Overflow 运行的第一天，还没有任何问题，你点击主页，什么，404 或只是 200 和“还没有问题”消息？

我正在尝试在 zend 框架中创建一个 REST 服务。我正在使用zend服务器。

这是我的代码：

HTTP 响应返回适当的标头和 JSON 数据，但在 JSON 数据下有一个 apache 错误文档。我能想到的删除附加错误文档的唯一方法是在我的 httpd.conf 文件中添加以下内容：

但是这样做的“正确”方式是什么？

我想下载一个文件，需要检查响应状态码（即HTTP /1.1 200 OK）。这是我的代码的片段：

我如何获得响应的状态码？

我使用这个伪类向服务器发出 Ajax 请求：

这是将要加载的 PHP：

当我实例化一个新对象并使用它加载请求时，它总是返回错误，并且状态码为 0。服务器正确生成了 XML 文档。为什么我无法取回正确的 200 代码？

我正在尝试对生产 Web 应用程序进行一些改进。在我的 WinXP IIS 5.1 开发机器上进行了相当多的单元测试后，一切都在我的本地主机上运行，​​所以我使用我的 Dev PC 上的 Visual Studio 2008 PUBLISH 对话框将以下项目推送到临时服务器：

• 主要网络应用
• “主要”网络服务（主页尝试调用此 WS）
• 一个“辅助”网络服务（还不是问题，因为主页没有调用这个 WS）

当我尝试浏览到 Web 应用程序的主页时，在我的浏览器中输入以下内容：myUglyURL

版本信息：Microsoft .NET Framework 版本：2.0.50727.3607；ASP.NET 版本：2.0.50727.3082

下面是一些相应的源代码：

我怀疑我可能在登台服务器上配置错误。临时服务器是运行 IIS 6.0 的 Win Server 2003 ServicePack 2。当我在名为 MOJITO 的登台服务器上发布主站点和 2 个 Web 服务时，我在 D 驱动器上为每个站点创建了物理目录。然后使用 INETMGR，我配置了以下虚拟目录：

• zVersion2
• zVersion2wsSQL
• zVersion2ws紧急情况

以上所有内容都配置为使用我设置并命名为zVersion2aspNet20的新应用程序池。此机器 MOJITO 的默认网站配置为使用 ASP.NET 1.1，并且 IP 地址设置为(All Unassigned)。后两个 web 服务的生产版本在 MOJITO 机器上运行（分别命名为 ZipeeeService 和 EmergencyService）。

我的上述 Web 服务的暂存版本（分别命名为 zVersion2wsSQL 和 zVersion2wsEmergency）是否可以在具有相同 IP 地址的同一 Web 服务器上共存？

请注意，当我独立测试 zVersion2wsSQL 网络服务（从 INETMGR 鼠标右键单击浏览）时，它按预期工作（即呈现网络服务的所有方法），如下所示：

• GetMessageByType MessageName="Get_x0020_Message_x0020_By_x0020_Type"

我可以通过单击它来测试这个 webmethod，它会显示 Test 对话框（因为它需要一个简单的数据类型，并且我在 localhost（即 MOJITO）上调用它：

我担心我可能已经讨论了太多信息，所以我会停下来，但我希望有人能帮助我，因为我不明白为什么这个请求会导致“未找到”。谢谢。

当用户未登录并尝试访问需要登录的页面时，重定向到登录页面的正确 HTTP 状态代码是什么？

我之所以问，是因为W3C 规定的 3xx 响应代码 似乎都不符合要求：

10.3.1 300 多项选择

请求的资源对应于一组表示中的任何一个，每个表示都有自己的特定位置，并且正在提供代理驱动的协商信息（第 12 节），以便用户（或用户代理）可以选择首选表示并重定向其请求该位置。

除非它是一个 HEAD 请求，否则响应应该包含一个实体，该实体包含一个资源特征和位置列表，用户或用户代理可以从中选择最合适的一个。实体格式由 ContentType 标头字段中给出的媒体类型指定。取决于格式和能力

用户代理，最合适的选择可能会自动执行。但是，本规范没有为这种自动选择定义任何标准。

如果服务器有首选的表示形式，它应该在 Location 字段中包含该表示形式的特定 URI；用户代理可以使用 Location 字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。

10.3.2 301 永久移动

请求的资源已被分配一个新的永久 URI，并且任何将来对该资源的引用都应该使用返回的 URI 之一。如果可能，具有链接编辑功能的客户端应该自动将对 Request-URI 的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

新的永久 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。

如果收到 301 状态代码以响应 GET 或 HEAD 以外的请求，用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

10.3.3 302 找到

请求的资源临时驻留在不同的 URI 下。由于重定向有时可能会改变，客户端应该继续使用 Request-URI 来处理未来的请求。此响应仅在由 Cache-Control 或 Expires 标头字段指示时才可缓存。

临时 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。

如果收到 302 状态码以响应 GET 或 HEAD 以外的请求，除非用户可以确认，否则用户代理不得自动重定向请求，因为这可能会改变发出请求的条件。

是 303 响应，无论原始请求方法如何，都对 Location 字段值执行 GET。状态码 303 和 307 已被添加用于希望明确明确期望客户端做出何种反应的服务器。

10.3.4 303 见其他

可以在不同的 URI 下找到对请求的响应，并且应该使用该资源上的 GET 方法来检索。此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。新的 URI 不是原始请求资源的替代引用。303 响应不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。

不同的 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。

10.3.5 304 未修改

如果客户端已经执行了一个条件 GET 请求并且允许访问，但是文档没有被修改，服务器应该用这个状态码来响应。304 响应不能包含消息体，因此总是由头字段之后的第一个空行终止。

响应必须包含以下标头字段：

无时钟源服务器遵循这些规则，并且代理和客户端将自己的 Date 添加到没有收到的任何响应中（如 [RFC 2068] 第 14.19 节已指定），缓存将正确运行。

第 13.3.3 节），响应不应包含其他实体标头。否则（即，条件 GET 使用弱验证器），响应不得包含其他实体标头；这可以防止缓存的实体主体和更新的标头之间的不一致。

如果 304 响应指示当前未缓存的实体，则缓存必须忽略响应并在没有条件的情况下重复请求。

如果缓存使用接收到的 304 响应来更新缓存条目，则缓存必须更新该条目以反映响应中给出的任何新字段值。

10.3.6 305 使用代理

请求的资源必须通过 Location 字段给出的代理访问。Location 字段给出了代理的 URI。接收者应该通过代理重复这个单一的请求。305 响应必须只能由源服务器生成。

10.3.7 306（未使用）

306 状态码在以前的规范版本中使用，不再使用，代码被保留。

10.3.8 307 临时重定向

请求的资源临时驻留在不同的 URI 下。由于重定向有时可能会改变，客户端应该继续使用 Request-URI 来处理未来的请求。此响应仅在由 Cache-Control 或 Expires 标头字段指示时才可缓存。

临时 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接，因为许多 HTTP/1.1 之前的用户代理不理解 307 状态。因此，注释应该包含用户在新 URI 上重复原始请求所需的信息。

如果收到 307 状态代码以响应 GET 或 HEAD 以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

我现在使用 302，直到我找到正确的答案。

更新和结论：

HTTP 302 更好，因为它与客户端/浏览器具有最佳兼容性。

我开发了一个 PHP 网络应用程序。我为用户提供了一次更新多个问题的选项。这样做时，有时用户会遇到此错误。有什么方法可以增加 apache 中 URL 的长度？