TIÊu chuẩn việt nam tcvn 11777-9: 2017 with amendment 5: 2014

Yêu cầu JPIP có thể được cung cấp cho một máy chủ đóng gói trong một yêu cầu HTTP "POST". Đối với yêu cầu "POST" các yêu cầu HTTP được giới hạn theo cách sau đây:

- "Method" sẽ là "POST".

- "entity-body" bằng không hoặc jpip-request-field được phân tách bởi "&".

- Dòng tiêu đề "Content-type:" nên bao gồm như "entity-header" và có giá trị "application / x- www-form-urlencoded".

Một ví dụ về yêu cầu JPIP đóng gói trong yêu cầu HTTP "POST" là:

Một yêu cầu tải lên là một yêu cầu HTTP hợp lệ bị hạn chế như sau:

- "Method" sẽ là "POST".

- URL phải chứa query-field tải lên.

- Content-type sẽ là loại ảnh của phần thân: image/jpt-stream, image/jpp-stream, hoặc một kiểu phương tiện truyền thông ảnh hoàn chỉnh.

Một ví dụ về yêu cầu JPIP tải lên là:

Một HTTP (hoặc HTTPS) truyền thông theo phiên được thiết lập bằng cách sử dụng các trường yêu cầu Kênh Mới với giá trị của "http" (hoặc "https"), tức là, "cnew = http" (hoặc "cnew = https") như là một phần được yêu cầu. Yêu cầu này thường được cung cấp bởi HTTP (hay HTTPS). Yêu cầu có thể chứa yêu cầu Cửa sổ hiển thị trở thành yêu cầu đầu tiên trong kênh mới. Đáp ứng của yêu cầu này sẽ được trả về trên cùng một kết nối với yêu cầu được thực hiện.

Máy khách có thể mở một kết nối HTTP (hay HTTPS) và phát đi một yêu cầu bao gồm tiêu đề HTTP (hay HTTPS) "Connection: keep-alive". Điều này rất hữu ích cho các phiên hiệu quả, nhưng nó không phải là cần thiết và cũng không đủ để có một phiên. Một kết nối HTTP (hay HTTPS) có thể được sử dụng cho lưu lượng đối với các địa chỉ khác nhau, các kênh khác nhau, hoặc thậm chí lưu lượng không phải JPIP, ví dụ: yêu cầu đối với tập tin HTML. Yêu cầu JPIP là một phần của phiên có thể đến trên kết nối HTTP (hay HTTPS) khác hơn so với kết nối HTTP (hay HTTPS) được sử dụng để yêu cầu và phát hành các kênh mới, mặc dù không khuyến khích điều này.

F.4 Đáp ứng

F.4.1 Tổng quan

Mỗi thành phần của đáp ứng trong Phụ lục D có thể được đóng gói như là một phần của đáp ứng HTTP hợp lệ.

Các đáp ứng JPIP truyền tải trên HTTP sẽ là các đáp ứng HTTP hợp lệ, với những hạn chế thêm vào một số phần của đáp ứng HTTP được mô tả trong các điều khoản dưới đây.

Tất cả các mã trạng thái được liệt kê trong Điều D.1.3 có thể được sử dụng trực tiếp như mã trạng thái HTTP. Ngoài ra một máy chủ cung cấp JPIP trên HTTP có thể sử dụng bất kỳ mã trạng thái HTTP được coi là hữu ích, ví dụ, 402.

Tất cả dữ liệu Mệnh đề lý do được cung cấp trong Điều D.1.3 có thể được sử dụng trực tiếp như Mệnh đề lý do HTTP. Mệnh đề lý do sẽ phù hợp với mã trạng thái. Máy chủ cung cấp JPIP qua HTTP có thể sử dụng bất kỳ Mệnh đề lý do HTTP được coi là hữu ích, ví dụ, yêu cầu Thanh toán.

F.4.3 Thông tin tiêu đề

F.4.3.1 Tiêu đề JPIP

Các dòng tiêu đề trong Điều D.2 được tính là "entity-header" trong đáp ứng HTTP mà không sửa đổi.

Máy chủ cung cấp JPIP trên HTTP có thể sử dụng dòng tiêu đề HTTP "Accept:" được tìm thấy trong yêu cầu để xác định loại đáp ứng JPIP. Nếu yêu cầu có chứa tham số truy vấn "type =", kiểu trả về sẽ là một trong những loại được liệt kê trong kiểu tham số. Nếu yêu cầu có cả tham số truy vấn "type =" và dòng tiêu đề "Accept:", máy chủ có thể sử dụng các ưu tiên được xác định trong dòng "Accept:" để lựa chọn giữa các loại quy định trong tham số truy vấn "type =". Nếu không có tham số truy vấn "type =" trong các yêu cầu, máy chủ có thể chọn một kiểu trả về được hỗ trợ bởi máy chủ JPIP từ danh sách các loại trong "Accept:"

Lưu ý rằng các bộ nhớ tạm thời trong các proxy HTTP khác với bộ nhớ đệm và mô hình bộ nhớ đệm trong JPIP.

Bất cứ yêu cầu JPIP với một trường yêu cầu Kênh Mới là một phần của phiên và đáp ứng như vậy có thể không \được lưu đệm bởi máy chủ proxy HTTP. Tương tự như vậy, bất kỳ đáp ứng nào bao gồm tiêu đề đáp ứng Kênh Mới cũng là một phần của phiên. Trong cả hai trường hợp, đáp ứng của máy chủ nên bao gồm một dòng tiêu đề HTTP "Cache-Control:" với giá trị "no-cache".

F.4.3.4 Sử dụng tiêu đề Content-type

Máy chủ cung cấp JPIP trên HTTP nên bao gồm dòng tiêu đề "Content-type:", chỉ ra loại dữ liệu trong phần thân, phổ biến nhất là image/jpp-stream hoặc image/jpt-stream.

Các tiêu đề Redirect HTTP có thể hữu ích để thông báo cho máy khách rằng các nguồn đã di chuyển hoặc nên truy cập tới một máy chủ khác.

Lưu ý rằng các đáp ứng JPIP định nghĩa cách để chuyển hướng hiệu quả. Đáp ứng JPIP nên được tham chiếu trong phiên.

F.4.4 Phần thân

Các bản tin trong Phụ lục D được xem như phần thân của đáp ứng HTTP. Lưu ý rằng đáp ứng HTTP có một cơ chế để xác định độ dài của đáp ứng. Nếu máy chủ không có kế hoạch làm gián đoạn một đáp ứng, nó có thể cung cấp thông tin này với \dòng tiêu đề HTTP "Content-Length". Các phương pháp tham chiếu cho việc cung cấp độ dài là sử dụng dòng tiêu đề HTTP "Transfer-Encoding: chunked" và sau đó cung cấp cho phần thân trong các óausc dữ liệu có kích thước xác định bởi máy chủ và quy định trước. Không khuyến khích kết thúc một đáp ứng bằng cách đóng các kết nối HTTP.

Máy khách và máy chủ JPIP không cần phải sử dụng hoặc hỗ trợ phương pháp HTTP "HEAD". Một máy chủ lựa chọn để thực hiện phương pháp "HEAD" sẽ làm theo quy định tại Điều 9.4 của RFC 2616. Đặc biệt, "Phương thức HEAD giống hệt với GET, ngoại trừ các máy chủ sẽ không trả về phần thân bản tin trong đáp ứng."

Máy khách có thể thấy sự hữu ích của nó khi phát hành yêu cầu HTTP "HEAD" như một phương tiện để xác định xem máy chủ sẽ sửa đổi bất kỳ thông số yêu cầu theo quy định tại Phụ lục D. Máy khách không nên phát hành yêu cầu HTTP "HEAD" với các trường truy vấn mô hình bộ nhớ đệm vì sẽ khiến các máy chủ cập nhật mô hình bộ nhớ đệm.

Lưu ý máy khách có nhu cầu cập nhật các mô hình bộ nhớ đệm của máy chủ mà không nhận được một đáp ứng có thể sử dụng các trường yêu cầu Độ dài Đáp ứng Tối đa.

Máy chủ có thể từ chối bất kỳ hoặc tất cả các yêu cầu "HEAD". Không giống như yêu cầu HTTP "HEAD" điển hình đòi hỏi tương đối ít nỗ lực cho một máy chủ để thực hiện, Bộ cài máy chủ JPIP có thể có được dữ liệu từ một số vị trí trong địa chỉ logic, tính toán bản chất của đáp ứng, và sau đó loại bỏ phần thân của đáp ứng để đáp ứng với yêu cầu "HEAD".

F.5.2 Sử dụng phương pháp HTTP OPTIONS

Máy khách và máy chủ JPIP không cần phải sử dụng hoặc hỗ trợ phương pháp HTTP "OPTIONS".

Lưu ý HTTP định nghĩa cơ chế thẻ thực thể (ETag) tương tự như trường yêu cầu ID Địa chỉ JPIP trong đó nó được sử dụng để biểu thị những thay đổi trong tài nguyên. Nếu cả thẻ thực thể và địa chỉ ID có liên quan đến một tài nguyên, thì khuyến cáo rằng ETag quy định của HTTP được thay đổi bất cứ khi nào ID địa chỉ được thay đổi.

Do đáp ứng có chứa dữ liệu nén có thể rất lớn và mất nhiều thời gian để truyền tải, điều quan trọng là để có thể tạm dừng truyền tải. Trừ khi "Transfer-Encoding: chunked" được quy định, các yêu cầu HTTP quy định cụ thể toàn bộ chiều dài của phần thân trong tiêu đề "Content-Length:" hoặc báo hiệu kết thúc dữ liệu bằng cách đóng kết nối. Không những là tham chiếu trong giao thức tương tác, vì nó có thể cần thiết để chặn các đáp ứng hiện tại và gửi nhiều dữ liệu hơn trên cùng một kết nối cho một đáp ứng mới.

CHÚ THÍCH 1: Điều 19.4.6 của RFC 2616 cung cấp một thuật toán để loại bỏ các mã hòa truyền khúc dữ liệu.

CHÚ THÍCH 2: Mã hòa truyền khúc dữ liệu có thể hữu ích với JPIP khi được phân phối qua các giao thức khác HTTP.

Với một kênh trả về HTTP, máy chủ không nhận được phản hồi liên tục từ máy khách và có thể dễ dàng đẩy một lượng lớn dữ liệu vào đường truyền, sẽ được nhận đủ trước khi dữ liệu bất kỳ của một cửa sổ mới có thể được xử lý. Để duy trì đáp ứng, máy khách nên sử dụng trường yêu cầu Độ dài Đáp ứng Tối đa để điều chỉnh luồng lưu lượng và do đó duy trì đáp ứng. Máy khách nói chung cần phải thực hiện các thuật toán điều khiển lưu lượng của mình để điều chỉnh độ dài yêu cầu để thay đổi các điều kiện mạng.

(Quy định)

Sử dụng JPIP với các yêu cầu HTTP và các khai báo TCP

G.1 Tổng quan

Giao thức JPIP chính nó là trung tính đối với cơ chế truyền tải cơ bản đối với các yêu cầu của máy khách và đáp ứng máy chủ, ngoại trừ các yêu cầu kênh liên quan đại diện bởi trường yêu cầu Kênh Mới ("cnew") (xem C.3.3) và tiêu đề đáp ứng Kênh Mới ("JPIP-cnew ") (xem D.2.3), trong đó chi tiết transport-specific sẽ được thông báo. Tiêu chuẩn này định nghĩa ba cách thức truyền tải cụ thể được xác định bởi các chuỗi "http", "http-tcp" và "http- udp" trong chuỗi giá trị kết hợp với các yêu cầu Kênh mới. Phụ lục này cung cấp các chi tiết truyền tải thứ hai, sẽ được xác định trong văn bản này là HTTP-TCP. Truyền tải đầu tiên được xác định trong văn bản này là HTTP đã được mô tả trong Phụ lục F. Loại truyền tải thứ ba được xác định trong văn bản này là HTTP-UDP.

Truyền tải HTTP-TCP sử dụng chính xác cùng một cơ chế với truyền tải HTTP để gửi yêu cầu máy khách đến máy chủ và nhận các tiêu đề đáp ứng của máy chủ và mã trạng thái. Tuy nhiên, dữ liệu đáp ứng của máy chủ (không phải là tiêu đề đáp ứng) được phân phối qua kết nối TCP bổ trợ. Thông tin truyền tải trên kết nối TCP bổ trợ này giống với truyền tải phần thân của một đáp ứng thuần HTTP, ngoại trừ việc nó được đóng khung thành nhiều khúc dữ liệu, mỗi trong số đó có số thứ tự khúc dữ liệu.

Máy khách báo nhận một cách rõ ràng sự xuất hiện của mỗi khúc dữ liệu bằng cách gửi số thứ tự của nó trở lại cho máy chủ trên đường dẫn phản hồi lại của các kết nối TCP bổ trợ. Một trong những lợi ích của truyền tải HTTP-TCP là máy chủ nhận được các thông báo tăng dần của các khúc dữ liệu đáp ứng đến thông qua của cơ chế xác nhận của máy khách. Điều này cho phép các máy chủ quản lý luồng dữ liệu để duy trì đáp ứng nhanh và hiệu quả mạng lưới.

Mọi yêu cầu gửi qua truyền tải HTTP phải được mã hóa theo quy định của tiêu chuẩn HTTP.

G.2 Yêu cầu máy khách

Yêu cầu được chuyển tiếp trên các kênh chính chính xác như là các yêu cầu HTTP. Chúng có hình thức giống như các yêu cầu được phát hành trên kênh sử dụng truyền tải HTTP được mô tả trong Phụ lục F. Trong đó, các yêu cầu HTTP "GET" và "POST" có thể được sử dụng.

Một kênh mới có thể được thiết lập cho máy chủ JPIP bằng cách phát hành một yêu cầu bao gồm các trường yêu cầu Kênh Mới (xem C.3.3). Ví dụ, một yêu cầu như vậy có thể được phát hành bằng cách sử dụng HTTP, mặc dù nó cũng có thể cấp cho máy chủ JPIP cụ thể sử dụng cơ chế truyền tải bất kỳ phù hợp. Nếu đáp ứng của máy chủ (thông qua tiêu đề đáp ứng Kênh Mới trong Điều D.2.3) chỉ ra rằng một kênh mới đã được tạo ra để làm việc truyền tải HTTP-TCP, máy khách sẽ thiết lập kết nối TCP bổ trợ bằng cách sử dụng số cổng bổ trợ phản hồi lại thông qua tiêu đề đáp ứng Kênh Mới. Hơn nữa, yêu cầu trong đó bao gồm các trường yêu cầu Kênh Mới được xử lý như thể nó đã được phát hành mới tạo ra kênh truyền tải HTTP-TCP, có nghĩa là các dữ liệu đáp ứng được tạo ra bởi yêu cầu đó sẽ được phản hồi thông qua kết nối TCP bổ trợ, ngay vì nó đã được kết nối.

Để thiết lập kết nối TCP bổ trợ, máy khách đưa ra yêu cầu kết nối TCP đến máy chủ xác định thông qua tiêu đề đáp ứng Kênh Mới, trên cổng xác định bởi các tiêu đề đáp ứng Kênh Mới. Các máy khách sau đó ngay lập tức gửi dòng văn bản ASCII, bao gồm chuỗi ID Kênh mới, tiếp theo là cặp CR-LF liên tiếp. Đây là thông tin văn bản theo định hướng chỉ được phân phối qua kết nối TCP bổ trợ.

Máy khách sau đó chờ đợi để nhận dữ liệu đáp ứng của máy chủ qua kết nối TCP bổ trợ. Dữ liệu đáp ứng này không thể trống, vì mọi yêu cầu cấp cho kênh truyền tải HTTP-TCP có một dòng dữ liệu đáp ứng bao gồm ít nhất là bản tin EOR (xem D.3). Xem G.4 để biết thêm về điều này.

Tất cả dữ liệu đáp ứng được gửi bởi máy chủ thộng qua kết nối TCP bổ trợ được đóng khung thành khúc dữ liệu. Mỗi khúc dữ liệu bao gồm một tiêu đề khúc 8-byte, tiếp theo là phần thân của khúc chứa dữ liệu đáp ứng của máy chủ, như trong hình G.1. Từ 2-byte đầu tiên của tiêu đề khúc dữ liệu là một số nguyên kiểu big endian không dấu biểu diễn tổng chiều dài của khúc dữ liệu, bao gồm từ độ dài chính nó. Nội dung của 6 byte còn lại của tiêu đề khúc dữ liệu không được định nghĩa bởi tiêu chuẩn này. Chúng có thể được sử dụng cho các dấu hiệu máy chủ cụ thể bổ sung. Các máy khách sẽ trả về toàn bộ tiêu đề khúc dữ liệu 8-byte trong bản tin báo nhận khúc dữ liệu của nó.

Ngay khi nhận được khúc dữ liệu đáp ứng máy chủ trên kết nối TCP bổ trợ, máy khách phải gửi tiêu đề khúc dữ liệu 8-byte lại cho máy chủ như là dòng dữ liệu không đóng khung, sử dụng đường dẫn phản hồi kết nối TCP. Mỗi khúc dữ liệu nhận tương ứng với một bản tin báo nhận theo thứ tự.

Để đáp ứng từng yêu cầu của máy khách, máy chủ sẽ gửi đáp ứng HTTP trả lời lại một đoạn văn bản cho máy khách trên kênh chính. Đoạn văn bản trả lời có chứa mã trạng thái, mệnh đề lý do và tất cả các tiêu đề đáp ứng JPIP liên quan và bất kỳ tiêu đề đáp ứng HTTP thích hợp. Tuy nhiên, không có dữ liệu đáp ứng được trả về thông qua kênh chính. Vì lý do này, sẽ không có phần thân thực thể HTTP trong đáp ứng HTTP-TCP. Hoặc tiêu đề đáp ứng HTTP "Content-length:" hoặc "Transfer-encoding:" được sử dụng.

Dữ liệu đáp ứng được chuyển tiếp qua kênh TCP bổ trợ, đóng khung thành khúc dữ liệu theo cách được mô tả trong Điều G.3.2. Do truyền tải HTTP-TCP chỉ được sử dụng với phiên và với kiểu trả về ảnh dòng JPP và dòng JPT, dữ liệu đáp ứng không thay đổi bao gồm một chuỗi các bản tin dòng JPP hoặc dòng JPT.

Các dữ liệu đáp ứng thu được từ mỗí yêu cầu sẽ bao gồm toàn bộ các khúc dữ liệu, có nghĩa là không có khúc dữ liệu nào chứa dữ liệu đáp ứng được tạo ra để đáp ứng hai yêu cầu khác nhau.

Đáp ứng cho mỗi và mọi yêu cầu kết thúc bằng bản tin EOR (xem D.3), ngay cả khi dữ liệu đáp ứng rỗng. Bản tin EOR được coi là một phần của dữ liệu đáp ứng và được đóng khung vào khúc dữ liệu cùng với bản tin dòng JPP và dòng JPT thực tế.

Điều này có nghĩa là tất cả các yêu cầu đưa ra trên kênh JPIP truyền tải HTTP-TCP được tạo ra từ ít nhất một khúc dữ liệu đáp ứng không rỗng từ máy chủ và khúc dữ liệu cuối cùng được tạo ra để đáp ứng yêu cầu kết thúc với bản tin EOR.

Lưu ý rằng không cần khúc dữ liệu đáp ứng truyền tải HTTP-TCP được sắp xếp trên biên của bản tin.

G.5 TCP và trường yêu cầu độ dài (Tham khảo)

Có thể là rất ít hoặc không có lý do cho việc sử dụng các trường yêu cầu Độ dài Đáp ứng Tối đa trên kênh khai báo TCP, nơi mà các máy chủ có thể điều chỉnh một cách cẩn thận luồng dữ liệu đáp ứng tới máy khách để duy trì đáp ứng.

(Quy định)

Sử dụng JPIP trên các giao thức truyền tải khác

H.1 Tổng quan

Tiêu chuẩn này không xác định bất kỳ giao thức truyền tải cụ thể nào giao thông truyền tải "http" được mô tả trong Phụ lục F và giao thức "http-tcp" được mô tả trong Phụ lục G. Mục đích của phụ lục này là cung cấp các hướng dẫn về việc triển khai JPIP trên các giao thức truyền thông không đáng tin cậy và cung cấp một phương pháp tiếp cận chung có thể được áp dụng cho một loạt các giao thức giao tải.

Trong việc phát triển cách tiếp cận chung, phụ lục này có ích để phân chia các khía cạnh của truyền thông thành hai kết nối truyền tải logic, được gọi là "kết nối yêu cầu " và "kết nối dữ liệu". Mỗi kết nối logic được hiểu để cung cấp đường dẫn truyền thông thuận và ngược. Vai trò của các đường dẫn như sau:

- Đường dẫn kết nối yêu cầu thuận được sử dụng đề gửi các yêu cầu JPIP từ máy khách đến máy chủ.

- Đường dẫn kết nối yêu cầu ngược lại được sử dụng bởi các máy chủ để xác nhận nhận được yêu cầu và trả về đáp ứng tiêu đề cho máy khách.

- Đường dẫn kết nối dữ liệu thuận được sử dụng để gửi bản tin dòng JPIP từ máy chủ tới khách hàng.

- Đường dẫn kết nối dữ liệu ngược được sử dụng bởi khách hàng để báo nhận bản tin dòng JPIP từ máy chủ.

Chương trình đọc sẽ nhận thấy rằng những vai trò này là phù hợp đường dẫn truyền thông của hai kênh TCP được sử dụng bởi truyền tải "http-tcp" được mô tả trong Phụ lục G. Thực ra các Điều trong phụ lục này có thể được hiểu như là một phần mở rộng của truyền tải "http-tcp" để truyền thông không đáng tin cậy. Lưu ý, mặc dù phụ lục này được mô tả hai kết nối logic khác nhau, không có lý do gì mà không thể thực hiện truyền thông qua kết nối truyền tải duy nhất.

Cuối cùng, nó được giả định rằng mỗi kết nối logic cung cấp một trong hai loại dịch vụ sau đây:

a) Dịch vụ dòng có định hướng đáng tin cậy, chẳng hạn như được cung cấp bởi TCP.

b) Dịch vụ gói có định hướng không tin cậy (ví dụ, xem "http-UDP" tại Phụ lục K). Trong trường hợp này, các gói dữ liệu có thể đến không theo thứ tự hoặc không đến.

Hai kịch bản được xem xét trong phụ lục này. Trong trường hợp đầu tiên, đường dẫn kết nối yêu cầu được cho là cung cấp dịch vụ dòng có định hướng đáng tin cậy, nhưng đường dẫn kết nối dữ liệu không đáng tin cậy. Trong trường hợp thứ hai, cả hai đường dẫn kết nối yêu cầu và kết nối dữ liệu là không đáng tin cậy. Điều này có ích để xử lý hai kịch bản này theo thứ tự.

Trong điều này, kết nối yêu cầu là đáng tin cậy, có nghĩa là yêu cầu đến máy chủ để không mất mát, và đáp ứng máy chủ nhận được bởi máy khách theo thứ tự và cũng không mất mát. Trong trường hợp này, các trường yêu cầu và tiêu đề đáp ứng có thể được truyền thông chính xác như trong giao thức "http-tcp", và thực sự HTTP được khuyến khích cho việc truyền tải các yêu cầu và tiêu đề đáp ứng.

Các bản tin dòng JPIP, bao gồm cả bản tin EOR (xem D.3), được chia thành các gói và chuyển tiếp qua các kết nối dữ liệu không đáng tin cậy.

Các hướng dẫn chung sau đây cần quan sát khi xây dựng các truyền tải loại này:

a) Mỗi yêu cầu phải bao gồm trường yêu cầu ID Yêu cầu (xem C.3.5).

b) Đối với mỗi yêu cầu, sẽ có một bản tin EOR tương ứng, ngay cả khi không có bản tin dòng JPIP được gửi để đáp ứng yêu cầu này. Yêu cầu này cũng được áp dụng trong trường hợp truyền tải "http-tcp".

c) Mỗi gói kết nối dữ liệu được xây dựng bởi các máy chủ sẽ bao gồm các bản tin dòng JPIP và/hoặc bản tin EOR. Hơn nữa, bản tin dòng JPIP đầu tiên trong mỗi gói phải có một tiêu đề đầy đủ, chứ không phải dựa vào sự lặp lại của các định danh dòng mã hoặc thành phần mã lớp của bản tin trước đó.

d) Tất cả các bản tin dòng JPIP (không nhất thiết có bản tin EOR) được tìm thấy trong gói kết nối dữ liệu thuộc đáp ứng của một yêu cầu duy nhất, và các yêu cầu tương ứng với ID Yêu cầu được mã hóa trong tiêu đề của gói.

e) Bản tin EOR có thể được tìm thấy hoặc ở phần cuối của gói cùng mang giá trị ID Yêu cầu như yêu cầu có đáp ứng đã kết thúc, hoặc trong khối chứa một hoặc nhiều bản tin EOR liên tiếp tìm thấy vào lúc bắt đầu gói đầu tiên ngay sau gói cuối cùng mang ID Yêu cầu đó. Chính sách này cho phép bản tin EOR tương ứng với một hoặc nhiều đáp ứng rỗng liên tiếp (ví dụ như do yêu cầu bị chặn) được đóng gói vào gói đầu tiên của đáp ứng không trống tiếp theo.

f) Ngoài giá trị ID Yêu cầu, mỗi tiêu đề gói nên bao gồm một số thứ tự gói. Thứ tự gói được thiết lập bằng 0 cho gói đầu tiên kết hợp với giá trị ID Yêu cầu bất kỳ cụ thể. Các gói dữ liệu tiếp theo với cùng giá trị ID Yêu cầu sẽ có số thứ tự liên tiếp. Chính sách này cho phép máy khách xác định bản tin EOR bất kỳ có thể chưa được nhận do mất gói. Điều quan trọng là máy khách có thể kết hợp với các yêu cầu dữ liệu đáp ứng, để đồng bộ các ảnh hưởng của các báo cáo thao tác mô hình bộ nhớ đệm tại máy chủ với trạng thái của bộ nhớ đệm của riêng mình.

g) Các máy khách xác nhận việc nhận được từng gói bằng cách gửi bản tin báo nhận đến máy chủ trên đường dẫn kết nối dữ liệu đáp ứng. Mỗi bản tin báo nhận cần có một bản sao tiêu đề các gói tin nhận được, nhưng cũng có thể chứa thêm thông tin. Các máy khách có thể quyết định gộp các bản tin báo nhận cho một số gói khi xây dựng các gói tin báo nhận. Tuy nhiên, việc gộp quá mức có thể ảnh hưởng đến độ tin cậy mà các máy chủ ước tính số liệu thống kê mạng.

h) Các máy chủ không bắt buộc phải truyền lại bất kỳ gói không xác nhận và máy khách không nên đợi truyền lại các gói bị mất. Một máy chủ thông minh có thể chọn để truyền lại các gói xác nhận phụ thuộc vào sự liên quan của chúng cửa sổ hiển thị hiện hành.

Điều này liên quan đến các truyền tải mà cả kết nối yêu cầu và dữ liệu đều không tin cậy. Hướng dẫn đối với kết nối dữ liệu được mô tả trong H.2 cho trường hợp dữ liệu được chuyển tiếp không chính xác. Với kết nối yêu cầu không tin cậy, nó có thể là một hoặc nhiều yêu cầu bị mất hoặc đến không theo trật tự tại các máy chủ. JPIP cũng được điều chỉnh để xử lý tình trạng này, do các máy chủ có quyền tự do chặn trước các yêu cầu trước đó khi một yêu cầu mới đến.

Các hướng dẫn chung sau đây cần quan sát khi xử lý yêu cầu không tin cậy, ngoài những mục được liệt kê trong H.2 đối với các kết nối dữ liệu không tin cậy.

a) Mỗi gói yêu cầu phải bao gồm một tiêu đề, xác định giá trị của ID Yêu cầu.

b) Mỗi gói yêu cầu cũng nên bao gồm số thứ tự, chứa đầy đủ thông tin để xác định có hay không tất cả các gói dữ liệu liên quan đến yêu cầu đã được nhận.

c) Trong nhiều trường hợp, máy chủ có thể đơn giản bỏ qua các gói tin yêu cầu bị mất khi một yêu cầu mới đến. Để làm điều này, máy chủ chỉ gửi bản tin EOR trên kết nối dữ liệu, chỉ ra rằng yêu cầu bị mất bị chặn ngay lập tức. Không cần gửi đi bản tin báo nhận để đáp ứng với các gói yêu cầu. Không cần gửi đi bất kỳ tiêu đề đáp ứng để đáp ứng với yêu cầu đang bị chặn ngay lập tức do một số hoặc tất cả các gói yêu cầu đã bị mất.

d) Đối với mỗi yêu cầu đến đầy đủ tại các máy chủ, máy chủ sẽ gửi một hay nhiều gói đáp ứng xác định các ID Yêu cầu và bao gồm tiêu đề đáp ứng bất kỳ. Điều này đúng ngay cả khi yêu cầu đến sau khi đáp ứng đã được gửi cho yêu cầu bất kỳ tiếp theo (ví dụ, do một số gói của các yêu cầu đã bị trì hoãn quá mức). Điều này cung cấp cho máy khách một cơ chế để xác định có hay không một yêu cầu quan trọng đã được nhận bởi máy chủ.

e) Một số loại yêu cầu sẽ được xử lý bởi các máy chủ để tránh mất đồng bộ với máy khách. Điều quan trọng nhất trong số này các yêu cầu bao gồm các trường thao tác bớt đi mô hình bộ nhớ đệm. Để kích hoạt máy chủ phát hiện các yêu cầu như vậy, mà không cần phải theo trình tự các dòng yêu cầu, yêu cầu tiêu đề gói nên bao gồm hai trường sau đây:

1) Cờ chỉ ra có hay không các gói thuộc một yêu cầu sẽ được xử lý trước khi xử lý yêu cầu tiếp theo.

2) ID Yêu cầu kết hợp với các yêu cầu gần nhất mà Cờ đề cập trong e1 được thiết lập.

Nếu máy chủ không nhận được một hoặc nhiều gói yêu cầu với bộ e1 Cờ (ví dụ, yêu cầu với điều kiện e2 đến và yêu cầu với cờ e1 bị mất), sẽ rảnh rỗi cho đến khi máy khách truyền lại các gói.