Java HttpHeaders.getHeader方法代码示例

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
/**
 * Extracts the entity body from a FullHttpMessage, according to the character set in the message's Content-Type header. If the Content-Type
 * header is not present or does not specify a charset, assumes the ISO-8859-1 character set (see {@link BrowserMobHttpUtil#DEFAULT_HTTP_CHARSET}).
 *
 * @param httpMessage HTTP message to extract entity body from
 * @return String representation of the entity body
 * @throws java.nio.charset.UnsupportedCharsetException if there is a charset specified in the content-type header, but it is not supported
 */
public static String extractHttpEntityBody(FullHttpMessage httpMessage) {
    Charset charset;
    try {
        charset = getCharsetFromMessage(httpMessage);
    } catch (UnsupportedCharsetException e) {
        // the declared character set is not supported, so it is impossible to decode the contents of the message. log an error and throw an exception
        // to alert the client code.
        java.nio.charset.UnsupportedCharsetException cause = e.getUnsupportedCharsetExceptionCause();

        String contentTypeHeader = HttpHeaders.getHeader(httpMessage, HttpHeaders.Names.CONTENT_TYPE);
        log.error("Cannot retrieve text contents of message because HTTP message declares a character set that is not supported on this platform. Content type header: {}.", contentTypeHeader, cause);

        throw cause;
    }

    return extractHttpEntityBody(httpMessage, charset);
}
 

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
/**
 * Derives the charset from the Content-Type header in the HttpMessage. If the Content-Type header is not present or does not contain
 * a character set, this method returns the ISO-8859-1 character set. See {@link BrowserMobHttpUtil#readCharsetInContentTypeHeader(String)}
 * for more details.
 *
 * @param httpMessage HTTP message to extract charset from
 * @return the charset associated with the HTTP message, or the default charset if none is present
 * @throws UnsupportedCharsetException if there is a charset specified in the content-type header, but it is not supported
 */
public static Charset getCharsetFromMessage(HttpMessage httpMessage) throws UnsupportedCharsetException {
    String contentTypeHeader = HttpHeaders.getHeader(httpMessage, HttpHeaders.Names.CONTENT_TYPE);

    Charset charset = BrowserMobHttpUtil.readCharsetInContentTypeHeader(contentTypeHeader);
    if (charset == null) {
        return BrowserMobHttpUtil.DEFAULT_HTTP_CHARSET;
    }

    return charset;
}
 

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
/**
 * Retrieves the Content-Type header of this message. If no Content-Type is present, returns the assumed default Content-Type (see
 * {@link BrowserMobHttpUtil#UNKNOWN_CONTENT_TYPE}).
 *
 * @return the message's content type
 */
public String getContentType() {
    String contentTypeHeader = HttpHeaders.getHeader(httpMessage, HttpHeaders.Names.CONTENT_TYPE);
    if (contentTypeHeader == null || contentTypeHeader.isEmpty()) {
        return BrowserMobHttpUtil.UNKNOWN_CONTENT_TYPE;
    } else {
        return contentTypeHeader;
    }
}
 

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
protected void captureResponseMimeType(HttpResponse httpResponse) {
    Log.e("InnerHandle", "captureResponseMimeType " + harEntry.getId());
    String contentType = HttpHeaders.getHeader(httpResponse, HttpHeaders.Names.CONTENT_TYPE);
    // don't set the mimeType to null, since mimeType is a required field
    if (contentType != null) {
        harResponse.getResponse().getContent().setMimeType(contentType);
    }
}
 

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
protected void captureRedirectUrl(HttpResponse httpResponse) {
    Log.e("InnerHandle", "captureRedirectUrl " + harEntry.getId());
    String locationHeaderValue = HttpHeaders.getHeader(httpResponse, HttpHeaders.Names.LOCATION);
    if (locationHeaderValue != null) {
        harResponse.getResponse().setRedirectURL(locationHeaderValue);
    }
}
 

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
protected void captureContentEncoding(HttpResponse httpResponse) {
    contentEncoding = HttpHeaders.getHeader(httpResponse, HttpHeaders.Names.CONTENT_ENCODING);
}
 

import io.netty.handler.codec.http.HttpHeaders; //导入方法依赖的package包/类
/**
 * Returns true if the HTTP response from the server is expected to indicate its own message length/end-of-message. Returns false
 * if the server is expected to indicate the end of the HTTP entity by closing the connection.
 * <p/>
 * This method is based on the allowed message length indicators in the HTTP specification, section 4.4:
 * <pre>
     4.4 Message Length
     The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

     1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.
     2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.
     3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding
     header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
     [LP note: multipart/byteranges support has been removed from the HTTP 1.1 spec by RFC 7230, section A.2. Since it is seldom used, LittleProxy does not check for it.]
     5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)
 * </pre>
 *
 * The rules for Transfer-Encoding are clarified in RFC 7230, section 3.3.1 and 3.3.3 (3):
 * <pre>
     If any transfer coding other than
     chunked is applied to a response payload body, the sender MUST either
     apply chunked as the final transfer coding or terminate the message
     by closing the connection.
 * </pre>
 *
 *
 * @param response the HTTP response object
 * @return true if the message will indicate its own message length, or false if the server is expected to indicate the message length by closing the connection
 */
public static boolean isResponseSelfTerminating(HttpResponse response) {
    if (isContentAlwaysEmpty(response)) {
        return true;
    }

    // if there is a Transfer-Encoding value, determine whether the final encoding is "chunked", which makes the message self-terminating
    List<String> allTransferEncodingHeaders = getAllCommaSeparatedHeaderValues(HttpHeaders.Names.TRANSFER_ENCODING, response);
    if (!allTransferEncodingHeaders.isEmpty()) {
        String finalEncoding = allTransferEncodingHeaders.get(allTransferEncodingHeaders.size() - 1);

        // per #3 above: "If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored."
        // since the Transfer-Encoding field is present, the message is self-terminating if and only if the final Transfer-Encoding value is "chunked"
        return HttpHeaders.Values.CHUNKED.equals(finalEncoding);
    }

    String contentLengthHeader = HttpHeaders.getHeader(response, HttpHeaders.Names.CONTENT_LENGTH);
    if (contentLengthHeader != null && !contentLengthHeader.isEmpty()) {
        return true;
    }

    // not checking for multipart/byteranges, since it is seldom used and its use as a message length indicator was removed in RFC 7230

    // none of the other message length indicators are present, so the only way the server can indicate the end
    // of this message is to close the connection
    return false;
}