简介

上一篇文章，咱们搭建了一个反对中文的HTTP服务器，并且可能从浏览器拜访，并获取到相应的后果。尽管浏览器在日常的利用中很广泛，然而有时候咱们也有可能从自建的客户端来调用HTTP服务器的服务。

明天给大家介绍如何自建一个HTTP客户端来和HTTP服务器进行交互。

应用客户端构建申请

在上一篇文章中，咱们应用浏览器来拜访服务器，并失去到了响应的后果，那么如何在客户端构建申请呢？

netty中的HTTP申请能够分成两个局部，别离是HttpRequest和HttpContent。其中HttpRequest只蕴含了申请的版本号和音讯头的信息，HttpContent才蕴含了真正的申请内容信息。

然而如果要构建一个申请的话，须要同时蕴含HttpRequest和HttpContent的信息。netty提供了一个申请类叫做DefaultFullHttpRequest，这个类同时蕴含了两局部的信息，能够间接应用。

应用DefaultFullHttpRequest的构造函数，咱们就能够结构出一个HttpRequest申请如下：

HttpRequest request = new DefaultFullHttpRequest(                    HttpVersion.HTTP_1_1, HttpMethod.GET, uri.getRawPath(), Unpooled.EMPTY_BUFFER);

下面的代码中，咱们应用的协定是HTTP1.1，办法是GET，申请的content是一个空的buffer。

构建好根本的request信息之后，咱们可能还须要在header中增加一下额定的信息，比方connection，accept-encoding还有cookie的信息。

比方设置上面的信息：

request.headers().set(HttpHeaderNames.HOST, host);            request.headers().set(HttpHeaderNames.CONNECTION, HttpHeaderValues.CLOSE);            request.headers().set(HttpHeaderNames.ACCEPT_ENCODING, HttpHeaderValues.GZIP);

还有设置cookie：

request.headers().set(                    HttpHeaderNames.COOKIE,                    ClientCookieEncoder.STRICT.encode(                            new DefaultCookie("name", "flydean"),                            new DefaultCookie("site", "www.flydean.com")));

设置cookie咱们应用的是ClientCookieEncoder.encode办法，ClientCookieEncoder有两种encoder模式，一种是STRICT，一种是LAX。

在STRICT模式下，会对cookie的name和value进行校验和排序。

和encoder对应的就是ClientCookieDecoder，用于对cookie进行解析。

设置好咱们所有的request之后就能够写入到channel中了。

accept-encoding

在客户端写入申请的时候，咱们在申请头上增加了accept-encoding，并将其值设置为GZIP，示意客户端接管的编码方式是GZIP。

如果服务器端发送了GZIP的编码内容之后，客户端怎么进行解析呢？咱们须要对GZIP的编码格局进行解码。

netty提供了HttpContentDecompressor类，能够对gzip或者deflate格局的编码进行解码。在解码之后，会同时批改响应头中的“Content-Encoding”和“Content-Length”。

咱们只须要将其增加到pipline中即可。

和它对应的类是HttpContentCompressor，用于对HttpMessage和HttpContent进行gzip或者deflate编码。

所以说HttpContentDecompressor应该被增加到client的pipline中，而HttpContentCompressor应该被增加到server端的pipline中。

server解析HTTP申请

server须要一个handler来解析客户端申请过去的音讯。对于服务器来说，解析客户端的申请应该留神哪些问题呢？

首先要留神的是客户端100 Continue申请的问题。

在HTTP中有一个独特的性能叫做，100 (Continue) Status，就是说client在不确定server端是否会接管申请的时候，能够先发送一个申请头，并在这个头上加一个"100-continue"字段，然而临时还不发送申请body。直到接管到服务器端的响应之后再发送申请body。

如果服务器收到100Continue申请的话，间接返回确认即可：

if (HttpUtil.is100ContinueExpected(request)) {                send100Continue(ctx);            }    private static void send100Continue(ChannelHandlerContext ctx) {        FullHttpResponse response = new DefaultFullHttpResponse(HTTP_1_1, CONTINUE, Unpooled.EMPTY_BUFFER);        ctx.write(response);    }

如果不是100申请的话，server端就能够筹备要返回的内容了：

这里用一个StringBuilder来存储要返回的内容：

StringBuilder buf = new StringBuilder();

为什么要用StringBuf呢？是因为有可能server端一次并不能齐全承受客户端的申请，所以将所有的要返回的内容都放到buffer中，等全副承受之后再一起返回。

咱们能够向server端增加欢送信息，能够能够增加从客户端获取的各种信息：

buf.setLength(0);            buf.append("欢送来到www.flydean.com\r\n");            buf.append("===================================\r\n");            buf.append("VERSION: ").append(request.protocolVersion()).append("\r\n");            buf.append("HOSTNAME: ").append(request.headers().get(HttpHeaderNames.HOST, "unknown")).append("\r\n");            buf.append("REQUEST_URI: ").append(request.uri()).append("\r\n\r\n");

还能够向buffer中增加申请头信息：

HttpHeaders headers = request.headers();            if (!headers.isEmpty()) {                for (Entry<String, String> h: headers) {                    CharSequence key = h.getKey();                    CharSequence value = h.getValue();                    buf.append("HEADER: ").append(key).append(" = ").append(value).append("\r\n");                }                buf.append("\r\n");            }

能够向buffer中增加申请参数信息：

            QueryStringDecoder queryStringDecoder = new QueryStringDecoder(request.uri());            Map<String, List<String>> params = queryStringDecoder.parameters();            if (!params.isEmpty()) {                for (Entry<String, List<String>> p: params.entrySet()) {                    String key = p.getKey();                    List<String> vals = p.getValue();                    for (String val : vals) {                        buf.append("PARAM: ").append(key).append(" = ").append(val).append("\r\n");                    }                }                buf.append("\r\n");            }

要留神的是当读取到HttpContent的时候的解决形式。如果读取的音讯是HttpContent，那么将content的内容增加到buffer中：

if (msg instanceof HttpContent) {            HttpContent httpContent = (HttpContent) msg;            ByteBuf content = httpContent.content();            if (content.isReadable()) {                buf.append("CONTENT: ");                buf.append(content.toString(CharsetUtil.UTF_8));                buf.append("\r\n");                appendDecoderResult(buf, request);            }

那么怎么判断一个申请是否完结了呢？netty提供了一个类叫做LastHttpContent，这个类示意的是音讯的最初一部分，当收到这一部分音讯之后，咱们就能够判断一个HTTP申请曾经实现了，能够正式的返回音讯了：

if (msg instanceof LastHttpContent) {                log.info("LastHttpContent:{}",msg);                buf.append("END OF CONTENT\r\n");

要写回channel，同样须要构建一个DefaultFullHttpResponse，这里应用buffer来进行构建：

FullHttpResponse response = new DefaultFullHttpResponse(                HTTP_1_1, currentObj.decoderResult().isSuccess()? OK : BAD_REQUEST,                Unpooled.copiedBuffer(buf.toString(), CharsetUtil.UTF_8));

而后增加一些必须的header信息就能够调用ctx.write进行回写了。

总结

本文介绍了如何在client构建HTTP申请，并具体解说了HTTP server对HTTP申请的解析流程。

本文的例子能够参考：learn-netty4

本文已收录于 http://www.flydean.com/19-netty-http-client-request-2/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

欢送关注我的公众号:「程序那些事」,懂技术，更懂你！