請求頭壓縮

⑴ ios網路開發中請求頭的內容content-length是什麼類型

在HTTP協議中，有Content-Length的詳細解讀。Content-Length用於描述HTTP消息實體的傳輸長度the transfer-length of the message-body。在HTTP協議中，消息實體長度和消息實體的傳輸長度是有區別，比如說gzip壓縮下，消息實體長度是壓縮前的長度，消息實體的傳輸長度是gzip壓縮後的長度。
在具體的HTTP交互中，客戶端是如何獲取消息長度的呢，主要基於以下幾個規則：
響應為1xx，204，304相應或者head請求，則直接忽視掉消息實體內容。
如果有Transfer-Encoding，則優先採用Transfer-Encoding裡面的方法來找到對應的長度。比如說Chunked模式。
「如果head中有Content-Length，那麼這個Content-Length既表示實體長度，又表示傳輸長度。如果實體長度和傳輸長度不相等（比如說設置了Transfer-Encoding），那麼則不能設置Content-Length。如果設置了Transfer-Encoding，那麼Content-Length將被忽視」。這句話翻譯的優點饒，其實關鍵就一點：有了Transfer-Encoding，則不能有Content-Length。
Range傳輸。不關注，沒詳細看了：）
通過伺服器關閉連接能確定消息的傳輸長度。（請求端不能通過關閉連接來指明請求消息體的結束，因為這樣可以讓伺服器沒有機會繼續給予響應）。這種情況主要對應為短連接，即非keep-alive模式。
HTTP1.1必須支持chunk模式。因為當不確定消息長度的時候，可以通過chunk機制來處理這種情況。
在包含消息內容的header中，如果有content-length欄位，那麼該欄位對應的值必須完全和消息主題裡面的長度匹配。
「The entity-length of a message is the length of the message-body before any transfer-codings have been applied」
也就是有chunk就不能有content-length 。

其實後面幾條幾乎可以忽視，簡單總結後如下：
1、Content-Length如果存在並且有效的話，則必須和消息內容的傳輸長度完全一致。（經過測試，如果過短則會截斷，過長則會導致超時。）
2、如果存在Transfer-Encoding（重點是chunked），則在header中不能有Content-Length，有也會被忽視。
3、如果採用短連接，則直接可以通過伺服器關閉連接來確定消息的傳輸長度。（這個很容易懂）
結合HTTP協議其他的特點，比如說Http1.1之前的不支持keep alive。那麼可以得出以下結論：
1、在Http 1.0及之前版本中，content-length欄位可有可無。
2、在http1.1及之後版本。如果是keep alive，則content-length和chunk必然是二選一。若是非keep alive，則和http1.0一樣。content-length可有可無。

⑵ 驗證一個網站是否支持 br 壓縮演算法

chrome瀏覽器默認會發送請求頭的時候發送支持 哪些壓縮方法， 按 F12 可以查看到發送到伺服器的請求。
在伺服器的返回中，一般優先順序高的都會配置為 br ， 如果返回的數據採用了br，可以在返回的頭部信息中看到，如果沒有 可能就伺服器不支持br壓縮。

⑶ HTTP請求頭概述

HTTP請求頭概述 （HttpServletRequest） HTTP客戶程序（例如瀏覽器），向伺服器發送請求的時候必須指明請求類型（一般是GET或者POST）。如有必要，客戶程序還可以選擇發送其他的請求頭。大多數請求頭並不是必需的，但Content-Length除外。對於POST請求來說Content-Length必須出現。 下面是一些最常見的請HTTP請求頭概述 （HttpServletRequest）
HTTP客戶程序（例如瀏覽器），向伺服器發送請求的時候必須指明請求類型（一般是GET或者POST）。如有必要，客戶程序還可以選擇發送其他的請求頭。大多數請求頭並不是必需的，但Content-Length除外。對於POST請求來說Content-Length必須出現。
下面是一些最常見的請求頭

Accept：瀏覽器可接受的MIME類型。

Accept-Charset：瀏覽器可接受的字元集。

Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。

Accept-Language：瀏覽器所希望的語言種類，當伺服器能夠提供一種以上的語言版本時要用到。

Authorization：授權信息，通常出現在對伺服器發送的WWW-Authenticate頭的應答中。

Connection：表示是否需要持久連接。如果Servlet看到這里的值為「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁麵包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。

Content-Length：表示請求消息正文的長度。

Cookie：這是最重要的請求頭信息之一

From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。

Host：初始URL中的主機和埠。

If-Modified-Since：只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304「Not Modified」應答。

Pragma：指定「no-cache」值表示伺服器必須返回一個刷新後的文檔，即使它是代理伺服器而且已經有了頁面的本地拷貝。

Referer：包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。

User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用。

UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。

有關HTTP頭完整、詳細的說明，請參見http://www.w3.org/Protocols/的HTTP規范。

HTTP應答頭概述（HttpServletResponse）
Web伺服器的HTTP應答一般由以下幾項構成：一個狀態行，一個或多個應答頭，一個空行，內容文檔。設置HTTP應答頭往往和設置狀態行中的狀態代碼結合起來。例如，有好幾個表示「文檔位置已經改變」的狀態代碼都伴隨著一個Location頭，而401（Unauthorized）狀態代碼則必須伴隨一個WWW-Authenticate頭。

然而，即使在沒有設置特殊含義的狀態代碼時，指定應答頭也是很有用的。應答頭可以用來完成：設置Cookie，指定修改日期，指示瀏覽器按照指定的間隔刷新頁面，聲明文檔的長度以便利用持久HTTP連接，……等等許多其他任務。

設置應答頭最常用的方法是HttpServletResponse的setHeader，該方法有兩個參數，分別表示應答頭的名字和值。和設置狀態代碼相似，設置應答頭應該在發送任何文檔內容之前進行。

setDateHeader方法和setIntHeadr方法專門用來設置包含日期和整數值的應答頭，前者避免了把java時間轉換為GMT時間字元串的麻煩，後者則避免了把整數轉換為字元串的麻煩。

HttpServletResponse還提供了許多設置

setContentType：設置Content-Type頭。大多數Servlet都要用到這個方法。
setContentLength：設置Content-Length頭。對於支持持久HTTP連接的瀏覽器來說，這個函數是很有用的。
addCookie：設置一個Cookie（Servlet API中沒有setCookie方法，因為應答往往包含多個Set-Cookie頭）。
另外，如上節介紹，sendRedirect方法設置狀態代碼302時也會設置Location頭。

有關HTTP頭詳細和完整的說明，請參見http://www.w3.org/Protocols/規范。

HTTP應答頭 說明
Allow 伺服器支持哪些請求方法（如GET、POST等）。

Content-Encoding 文檔的編碼（Encode）方法。只有在解碼之後才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。

Content-Length 表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成後查看其大小，然後把該值放入Content-Length頭，最後通過byteArrayStream.writeTo(response.getOutputStream()發送內容。

Content-Type 表示後面的文檔屬於什麼MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由於經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。

Date 當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。

Expires 應該在什麼時候認為文檔已經過期，從而不再緩存它？

Last-Modified 文檔的最後改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲於指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。
Location 表示客戶應當到哪裡去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。

Refresh 表示瀏覽器應該在多少時間之後刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現，這是因為，自動刷新或重定向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是「N秒之後刷新本頁面或訪問指定頁面」，而不是「每隔N秒刷新本頁面或訪問指定頁面」。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬於HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。

Server 伺服器名字。Servlet一般不設置這個值，而是由Web伺服器自己設置。

Set-Cookie 設置和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。

WWW-Authenticate 客戶應該在Authorization頭中提供什麼類型的授權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=\"executives\"")。注意Servlet一般不進行這方面的處理，而是讓Web伺服器的專門機制來控制受密碼保護頁面的訪問（例如.htaccess）。

⑷ 在Chrome裡面能看出來某個網頁是否啟用了gzip壓縮嗎

在 Network 下可以看到一些頁面請求，再請求記錄的表頭右擊，勾選 「Content Encoding」，可以在出現的對應列里查看編碼，比如紅框里的「gzip」；

⑸ javaweb里get請求頭報文信息含義是什麼啊

常見的HTTP報文頭屬性

• Accpet

• 告訴服務端,客戶端接收什麼類型的響應

• Referer

• 表示這是請求是從哪個URL進來的,比如想在網上購物,但是不知道選擇哪家電商平台,你就去問度娘,說哪家電商的東西便宜啊,然後一堆東西彈出在你面前,第一給就是某寶,當你從這里進入某寶的時候,這個請求報文的Referer就是www..com

• Cache-Control

• 對緩存進行控制,如一個請求希望響應的內容在客戶端緩存一年,或不被緩可以通過這個報文頭設置

• Accept-Encoding

• 例如:Accept-Encoding:gzip, deflate(這兩種都是壓縮格式)

• 這個屬性是用來告訴伺服器能接受什麼編碼格式,包括字元編碼,壓縮形式(一般都是壓縮形式)

• Host

• 指定要請求的資源所在的主機和埠

• User-Agent 作用：告訴伺服器，客戶端使用的操作系統、瀏覽器版本和名稱

⑹ php curl 判斷url 是否有壓縮

用到的curl的兩個參數：
//在http 請求頭加入 gzip壓縮

curl_setopt($ch, CURLOPT_HTTPHEADER, array('Accept-Encoding:gzip'));
//curl返回的結果，採用gzip解壓
curl_setopt($ch, CURLOPT_ENCODING, "gzip");

⑺ HTTP協議：協議頭是什麼東西

當用戶打開一個網頁時，瀏覽器要向網站伺服器發送一個HTTP請求頭，然後網站伺服器根據HTTP請求頭的內容生成當次請求的內容發送給瀏覽器。

當用戶設計一個通信協議時，「消息頭/消息體」的分割方式是很常用的，消息頭告訴對方這個消息是干什麼的，消息體告訴對方怎麼干。HTTP傳輸的消息也是這樣規定的，每一個HTTP包都分為HTTP頭和HTTP體兩部分，後者是可選的，而前者是必須的。

(7)請求頭壓縮擴展閱讀

HTTP協議常用頭部實例

1、Accept：text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, image/apng, */*; q=0.8

作用：向伺服器申明客戶端（瀏覽器）可以接受的媒體類型（MIME）的資源

解釋：瀏覽器可以接受 text/html、application/xhtml+xml、application/xml類型，通配符*/* 表示任意類型的數據。並且瀏覽器按照該順序進行接收。( text/html —> application/xhtml+xml —> application/xml)

2、Accept-encoding: gzip, deflate, br

作用：向伺服器申明客戶端（瀏覽器）接收的編碼方法，通常為壓縮方法

解釋：瀏覽器支持採用經過 gzip，deflate 或 br 壓縮過的資源

⑻ 如何判斷該網頁是否開啟gzip之類的壓縮

在 Network 下可以看到一些頁面請求，再請求記錄的表頭右擊，勾選 「Content Encoding」，可以在出現的對應列里查看編碼，比如紅框里的「gzip」；

⑼ 如何在java REST API中用GZip和Jersey壓縮相應

有許多情景當你的REST api提供的相應是非常長的，並且我們都知道傳遞速度和貸款在移動設備/網路上是多重要。當開發支持REST apis的移動app的時候，我認為首要的性能最優化的點就是需要解決。猜猜是什麼？因為響應式文本，因此我們能壓縮這些文本。而且隨著當前的只能手機和平板的能力，在客戶端解壓文本應該不是個大問題...因此在這篇文章中，如果你使用java的Jersey構建它，我將介紹你怎麼能有選擇性的壓縮REST API響應，這個Jersey事JAX-RS的映射實現(還有更多)...

1.Jersey過濾器和攔截器

啊，感謝Jersey的強大的過濾器和攔截器特性，這個實現是相當容易的。然後過濾器是主要打算來維護像HTTP headers，URIs和/或HTTP methods的request和response的參數，攔截器是維護實體，通過維護實體的輸入/輸出流。

但是對於壓縮將使用一個GZip WriterInterceptor，一個寫攔截器被用於這種情況，在那個類里，實體被寫到"wire"，當在這種情況中時，它在伺服器這邊，這就意味著輸出一個響應實體。

1.1GZip Writer Interceptor

那讓我們來看看我們的GZip Writer Interceptor吧：

GZip Writer Interceptor

package org.codingpedia.demo.rest.interceptors;

import java.io.IOException;

import java.io.OutputStream;

import java.util.zip.GZIPOutputStream;

import javax.ws.rs.WebApplicationException;

import javax.ws.rs.core.MultivaluedMap;

import javax.ws.rs.ext.WriterInterceptor;

import javax.ws.rs.ext.WriterInterceptorContext;

@Provider

@Compress

public class GZIPWriterInterceptor implements WriterInterceptor {

@Override

public void aroundWriteTo(WriterInterceptorContext context)

throws IOException, WebApplicationException {

MultivaluedMap<String,Object> headers = context.getHeaders();

headers.add("Content-Encoding", "gzip");

final OutputStream outputStream = context.getOutputStream();

context.setOutputStream(new GZIPOutputStream(outputStream));

context.proceed();

}

}

注意：

它實現了WriterInterceptor，這是一個寫攔截器的消息體的介面，這個介麵包裝調用javax.ws.rs.ext.MessageBodyWriter.writeTo

供應商實現WriterInterceptor協議必須要麼以編程方式注冊進一個JAX-RS運行環境，要麼必須用@Provider註解來註解在一個提供商掃描語句期間自動的被JAX-RS運行環境發現。

@Compress是綁定註解的名稱，在接下來的段落中我們將更詳細的討論它

「攔截器從WriterInterceptorContext中獲得一個輸出流並且設置一個新的用原始的GZIP包裝器包裝的輸出流。在所有的攔截器被執行以後，輸出流最終設置WriterInterceptorContext將用於序列化實體。在上面的例子中，實體位元組將被寫到GZIPOutputStream中，這個類將壓縮流數據，然後把他們寫到原始輸出流。原始流總是把數據寫到wire中。當攔截器被用在伺服器上時，原始輸出流會把數據寫到底層伺服器容器的流中，然後發送響應給客戶端。」

「重載方法aroundWriteTo()獲取WriterInterceptorContextz作為參數。這個上下文包括請求頭參數getters和setters，請求屬性，實體，實體流和其它屬性；當你壓縮你的響應時，你應當設置'Content-Encoding'頭位gzip」

1.2 壓縮註解

過濾器和攔截器能被綁定名字。名稱綁定是一種概念，這種概念就是允許告訴一個JAX-RS的運行時，一個只為特定資源方法的特定的過濾器或者攔截器將被執行。當一個過濾器或者攔截器只對一些特定的資源方法限制，那我們就認為它是名稱綁定。過濾器和攔截器沒有這樣的限制就被稱作global。在我們的例子中我們已經構建了@Compress註解：

Compress annotation

package org.codingpedia.demo.rest.interceptors;

import java.lang.annotation.Retention;

import java.lang.annotation.RetentionPolicy;

import javax.ws.rs.NameBinding;

//@Compress annotation is the name binding annotation

@NameBinding

@Retention(RetentionPolicy.RUNTIME)

public @interface Compress {}

而且用它來標記在資源上的方法，這個方法應該是被壓縮的(eg:當GET-ing的時候，所有的博客用PodcastsResource)

@Compress annotation在資源方法上的使用

@Component

@Path("/podcasts")

public class PodcastsResource {

@Autowired

private PodcastService podcastService;

...........................

/*

* *********************************** READ ***********************************

*/

/**

* Returns all resources (podcasts) from the database

*

* @return

* @throws IOException

* @throws JsonMappingException

* @throws JsonGenerationException

* @throws AppException

*/

@GET

@Compress

@Proces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })

public List<Podcast> getPodcasts(

@QueryParam("orderByInsertionDate") String orderByInsertionDate,

@QueryParam("numberDaysToLookBack") Integer numberDaysToLookBack)

throws IOException,AppException {

List<Podcast> podcasts = podcastService.getPodcasts(

orderByInsertionDate, numberDaysToLookBack);

return podcasts;

}

...........................

}

2.測試

2.1SOAPui

好了，如果你正在用SOAPui測試，你能使用下面的請求違反PodcastsResource

Reqest:

請求例子：

GET http://localhost:8888/demo-rest-jersey-spring/podcasts/?orderByInsertionDate=DESC HTTP/1.1

Accept-Encoding: gzip,deflate

Accept: application/json, application/xml

Host: localhost:8888

Connection: Keep-Alive

User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Response:

被壓縮的json響應，通過SOAPui自動的解壓縮

HTTP/1.1 200 OK

Content-Type: application/json

Content-Encoding: gzip

Content-Length: 409

Server: Jetty(9.0.7.v20131107)

[

{

"id": 2,

"title": "Quarks & Co - zum Mitnehmen",

"linkOnPodcastpedia": "http://www.podcastpedia.org/quarks",

"feed": "http://podcast.wdr.de/quarks.xml",

"description": "Quarks & Co: Das Wissenschaftsmagazin",

"insertionDate": "2014-10-29T10:46:13.00+0100"

},

{

"id": 1,

"title": "- The Naked Scientists Podcast - Stripping Down Science",

"linkOnPodcastpedia": "http://www.podcastpedia.org/podcasts/792/-The-Naked-Scientists-Podcast-Stripping-Down-Science",

"feed": "feed_placeholder",

"description": "The Naked Scientists flagship science show brings you a lighthearted look at the latest scientific breakthroughs, interviews with the world top scientists, answers to your science questions and science experiments to try at home.",

"insertionDate": "2014-10-29T10:46:02.00+0100"

}

]

SOAPui接受Content-type:gzip頭，我們在GZIPWriterIntercepter中添加了並且自動的解壓了響應並且用人眼可讀的方式展示出來。

好了，就這些了。你已經了解了Jersey如何讓它直接壓縮REST api響應了。

⑽ 如何請求和響應http的post，head協議

WWW的核心——HTTP協議 眾所周知，Internet的基本協議是TCP/IP協議，目前廣泛採用的FTP、ArchieGopher等是建立在TCP/IP協議之上的應用層協議，不同的協議對應著不同的應用。<BR>WWW伺服器使用的主要協議是HTTP協議，即超文體傳輸協議。由於HTTP協議支持的服務不限於WWW，還可以是其它服務，因而HTTP協議允許用戶在統一的界面下，採用不同的協議訪問不同的服務，如FTP、Archie、SMTP、NNTP等。另外，HTTP協議還可用於名字伺服器和分布式對象管理。 2/zju/index.htmHTTP/1.0 頭信息又稱為元信息，即信息的信息，利用元信息可以實現有條件的請求或應答。 請求頭——告訴伺服器怎樣解釋本次請求，主要包括用戶可以接受的數據類型、壓縮方法和語言等。 實體頭——實體信息類型、長度、壓縮方法、最後一次修改時間、數據有效期等。 實體——請求或應答對象本身。 3.發送響應 伺服器在處理完客戶的請求之後，要向客戶機發送響應消息。 HTTP/1.0的響應消息格式如下： 響應消息=狀態行(通用信息頭響應頭實體頭)CRLF〔實體內容〕 狀態行=HTTP版本號狀態碼原因敘述 狀態碼表示響應類型 1××保留 2××表示請求成功地接收 3××為完成請求客戶需進一步細化請求 4××客戶錯誤 5××伺服器錯誤 響應頭的信息包括：服務程序名，通知客戶請求的URL需要認證，請求的資源何時能使用。 4.關閉連接 客戶和伺服器雙方都可以通過關閉套接字來結束TCP/IP對話