哪个java http客户端支持状态码102处理？答案

【问题标题】：Which java http client supports status code 102 Processing?哪个java http客户端支持状态码102处理？
【发布时间】：2014-05-19 08:35:17
【问题描述】：

我们公司应该通过 HTTP 调用类似 REST 的服务，该服务响应状态码 102 Processing 以进行冗长（耗时）的操作。据我了解，102 处理并不是真正的官方 HTTP 标准的一部分，而是an extension for the WebDAV protocol。也就是说，我们尝试访问的不是 WebDAV，而是“借用”此状态码的 HTTP 服务。

哪个 java 库支持这个？

【问题讨论】：

“支持”是什么意思？在服务器端，您可以编写任何类型的 REST 服务，可以将（几乎）任何值设置为响应状态代码。在客户端（几乎）任何 http 库都会读取响应并返回状态代码和响应正文，无论它们是什么。 102 Processing 值本身并没有什么特别之处。
@OlegEstekhin 这是我正在寻找的客户端。 102 是临时响应，意思是“等等，还有更多，但我需要一些时间”，我认为这需要对客户进行一些特殊处理。
您必须自己编写特殊处理代码，例如当您执行请求并获得 102 时，您应该再次重新安排（相同）请求或显示一些消息要求用户等待并单击一些按钮。 http 库知道如何“从技术上”处理 102 - 将状态码传递给您，但它不知道如何“从语义上”处理它 - 重新安排/询问用户/...，因此您必须这样做。
奥列格，你完全错了！这不是简单的回应。服务器发送 102，并且不关闭连接。然后可以再次发送102，多次，最后200ok有数据。在同一个连接中。所以没有调度相同的请求，这会导致服务器重新计算。如果没有库支持，这将很难。

标签： java http webdav

【解决方案1】：

1) HTTP 规范定义了一个状态码注册表（http://www.iana.org/assignments/http-status-codes）；描述状态代码的规范并不重要。

2) 话虽如此，RFC 4918（已淘汰 RFC 2518）不再定义代码 102（因为缺少任何实现）。

【讨论】：

有趣。但是，我似乎偶然发现了一个（服务器端）实现，尽管不是在 WebDAV 上下文中。

【解决方案2】：

首先，102 PROCESSING 状态在以下情况下似乎很有用：

该操作运行时间很长，例如，一些复杂的级联数据库删除操作，或者在 WebDAV 上，一个大目录深拷贝等。

我需要这个，因为在某些环境中访问是通过防火墙并且有 5 分钟超时。如果超过 5 分钟没有通过 TCP 连接，则连接关闭。在服务器端这显示为 IOError 连接关闭，在客户端这也显示为连接关闭或超时错误消息。

我们使用 102 PROCESSING 是因为在我们可以写入 servlet 输出流之前，我们需要保持我们的选项打开以仍然以最终的 200、300（重定向）或 400（错误）回复。

102 PROCESSING 确实没有得到很好的支持。 JETTY（服务器）有一些基本的实现，我用一个单独的线程在它上面制作了一些东西，它会休眠 5 分钟，检查 servlet 输出流是否仍未提交，然后发出 response.sendProcessing() 并再次进入休眠状态。一旦写入实际输出，线程就会被终止。

Apache HTTPD 如果用作此 JETTY 实现的反向代理，则可以很好地传递这 102 个 PROCESSING 响应。但是在其中的 10 个之后，它会引发错误。

sun.net.www.protocol.http.HttpURLConnection 不能很好地处理这个问题。我有一个小测试程序：

import java.net.URL;
import java.net.URLConnection;
import java.net.HttpURLConnection;
import java.io.*;

public class urlcontest {
    public static void main(String args[]) throws Exception {
        URLConnection conn = new URL(args[0]).openConnection();
        System.err.println("URLConnection class: " + conn.getClass());
        if(args.length > 1)
            conn.setRequestProperty("Cookie",args[1]);
        conn.setAllowUserInteraction(false);
        conn.setDoOutput(false);
        conn.setDoInput(true);
        InputStream in = null;
        if(conn instanceof HttpURLConnection) {
            HttpURLConnection hconn = (HttpURLConnection)conn;
            int responseStatus = hconn.getResponseCode();
            try {
                in = hconn.getInputStream();
                System.err.println("HTTP input: " + responseStatus);
            } catch(IOException e) {
                System.err.println("HTTP error: " + responseStatus);
                in = ((HttpURLConnection)conn).getErrorStream();
            }
        } else
            in = conn.getInputStream();
        byte[] buf = new byte[4096];
        int nread = 0;
        while((nread = in.read(buf)) > 0)
            System.out.write(buf, 0, nread);
        in.close();
    }
}

有了这个，我得到以下行为：

URLConnection class: class sun.net.www.protocol.http.HttpURLConnection
HTTP input: 102
HTTP/1.1 102 Processing

HTTP/1.1 102 Processing

HTTP/1.1 102 Processing

HTTP/1.1 301 Moved Permanently
Location: ...
Content-Type: text/html
Content-Length: ...
Server: Jetty(6.0.1)

<html>...</html>

因此，很明显，它将第一个 102 PROCESSING 作为最终响应，然后从输入流中读取其他所有内容，并在暂停期间阻塞。

如果我能找到这个或另一个 HttpURLConnection 实现的源代码，我会做一些事情让它工作。

不知何故，它也应该已经处理了 100 CONTINUE 响应。做起来应该不会太难。

【讨论】：

FWIW，这是一个记录在案的错误：bugs.openjdk.java.net/browse/JDK-8170305>