What là một tiêu đề HTTP? Các trường yêu cầu và phản hồi được giải thích

What là tiêu đề HTTP?

Một tiêu đề HTTP là một trường đính kèm với một thông điệp HTTP truyền đạt siêu dữ liệu về yêu cầu, phản hồi, đại diện, quản lý kết nối, ngữ cảnh xác thực, bộ nhớ đệm hoặc thương lượng. Một trường có tên không phân biệt chữ hoa chữ thường và một hoặc nhiều giá trị được diễn giải theo định nghĩa của trường đó. Các tiêu đề định hình cách một thông điệp được xử lý, nhưng phần thân của thông điệp mang theo đại diện thực sự.

Định nghĩa hữu ích bao gồm cả cơ chế và ranh giới của nó. Tiêu đề HTTP ảnh hưởng đến một phần cụ thể của một giao dịch, trong khi các trách nhiệm liền kề vẫn thuộc về HTTP, trình duyệt, phương tiện vận chuyển được chọn, ứng dụng, hoặc mô hình dữ liệu của máy chủ. Giữ các lớp đó tách biệt giúp báo cáo lỗi có thể tái tạo và ngăn chặn một thay đổi cấu hình bị hiểu nhầm là một quyết định kiểm soát truy cập.

Đối với các nhà phát triển API, câu hỏi đầu tiên là ai tạo ra giá trị hoặc hành vi. Câu hỏi tiếp theo là ai diễn giải nó. Câu hỏi cuối cùng là kết quả có thể quan sát nào chứng minh rằng việc diễn giải đã hoạt động. Ba câu trả lời đó biến một thuật ngữ trong từ điển thành một hợp đồng giao diện có thể kiểm tra.

Các trường tiêu đề di chuyển như thế nào qua một giao dịch HTTP

Một tác nhân người dùng xây dựng một dòng yêu cầu hoặc tập hợp trường HTTP/2, thêm các trường tiêu đề yêu cầu và có thể đính kèm một phần thân. Máy chủ gốc đọc các trường như Host hoặc :authority, Accept, Authorization, Cookie, và Content-Type để định tuyến yêu cầu và diễn giải đại diện của nó. Mỗi trường có cú pháp và ngữ nghĩa riêng; không có quy tắc phổ quát nào cho rằng mỗi dấu phẩy phân tách các giá trị.

Máy chủ trả về một trạng thái, các trường phản hồi, và thường là một đại diện. Content-Type mô tả loại phương tiện đại diện, Content-Encoding mô tả một mã hóa nội dung được áp dụng, Cache-Control mang theo các chỉ dẫn bộ nhớ đệm, và Set-Cookie yêu cầu một tác nhân người dùng lưu trữ trạng thái theo quy tắc cookie. Những trường này có liên quan nhưng không thể thay thế cho nhau.

Các trung gian có thể chuyển tiếp, thêm, xóa hoặc biến đổi các trường khi đặc điểm kỹ thuật hoặc triển khai cho phép điều đó. Các trường kết nối hop-by-hop có các quy tắc chuyển tiếp khác với siêu dữ liệu đại diện end-to-end. Do đó, việc gỡ lỗi ghi lại cả yêu cầu phát ra bởi khách hàng và phản hồi nhận được sau các trung gian.

HTTP/2 và HTTP/3 mã hóa các trường khác nhau trên đường kết nối so với HTTP/1.1, nhưng các ứng dụng thường làm việc với cùng một ngữ nghĩa trường. Các trường pseudo-header như :method là dữ liệu điều khiển giao thức cho những phiên bản đó và không phải là các tiêu đề tùy chỉnh thông thường.

Bản đồ tiêu đề từng trường

Các thuật ngữ sau phân tách các thành phần thường bị nén thành một nhãn. Đọc chúng như là các giao diện giữa các bên tham gia thay vì như trang trí trong một bản theo dõi mạng.

Tại sao tiêu đề HTTP lại quan trọng trong việc thu thập dữ liệu web

Tiêu đề HTTP có thể thay đổi những gì byte đến, cách những byte đó được diễn giải, hoặc liệu mã trình duyệt có thể quan sát kết quả hay không. Một quy trình thu thập nên xác định hiệu ứng đó trước khi thay đổi công cụ. Ghi lại URL đã yêu cầu, URL cuối cùng, trạng thái phản hồi, loại đại diện, các trường giao thức liên quan, và một dấu hiệu nội dung mong đợi. Bản ghi ngắn gọn đó phân biệt một trang đúng với một thông điệp truy cập, màn hình đồng ý, mục tiêu chuyển hướng, hình dạng ứng dụng trống, hoặc mã hóa không tương thích.

HTTP trực tiếp là con đường thu thập đơn giản nhất khi dữ liệu cần thiết tồn tại trong phản hồi do máy chủ mở cung cấp. Một trình duyệt trở nên có liên quan khi nội dung được chấp nhận phụ thuộc vào việc thực thi JavaScript, trạng thái do trình duyệt quản lý, điều hướng, hoặc chính sách bảo mật của trình duyệt. Hai con đường này không nên bị buộc phải trông giống nhau: các trình duyệt quản lý cookie, nén, chuyển hướng, CORS, và lưu trữ theo quy tắc của nền tảng, trong khi một khách hàng trực tiếp phơi bày một tập hợp mặc định khác.

Liên tục phiên làm việc quan trọng bất cứ khi nào một phản hồi thiết lập trạng thái cho yêu cầu tiếp theo. Giữ một chuỗi được ủy quyền trong một bối cảnh khách hàng giới hạn, bảo tồn ngôn ngữ và nguồn mạng cần thiết, và tránh trộn lẫn trạng thái từ những công việc không liên quan.

Phân tích chỉ bắt đầu sau khi xác thực đại diện. Xác nhận máy chủ cuối cùng, danh tính chuẩn xác nếu có, loại phương tiện, trạng thái giải mã và dấu hiệu kinh doanh cần thiết trước khi trích xuất các trường. Thứ tự này ngăn một bộ phân tích biến tài liệu lỗi thành các bản ghi rỗng mà có vẻ thành công về mặt kỹ thuật.

Các trung gian xứng đáng được chú ý rõ ràng. Mạng phân phối nội dung có thể chọn một biến thể mã hóa, một cổng có thể trả lời OPTIONS, một bộ nhớ đệm có thể tái sử dụng một phản hồi đã đàm phán, và một máy chủ ứng dụng có thể thiết lập cookie hoặc các trường ủy quyền. So sánh chỉ mã ứng dụng với đầu ra trang cuối cùng bỏ qua lớp có thể đã đưa ra quyết định.

API Scraping Universal Không Phế Thải có liên quan khi một nhóm cần thu hồi quản lý nội dung công cộng được phép, bao gồm các trang được hiển thị bằng JavaScript. Hợp đồng thu hồi vẫn nên định nghĩa mục tiêu, các trường cho phép, đại diện mong đợi, dấu hiệu chấp nhận và điều kiện dừng. Khả năng sản phẩm không thay thế các điều khoản nguồn, đánh giá quyền riêng tư, hoặc xác thực mức ứng dụng.

Tại sao Header lại quan trọng trong công việc dữ liệu web

Header HTTP có vị trí trong một kiến trúc khi nó thay đổi hành vi sản phẩm cụ thể, yêu cầu tương thích, hoặc quyết định chẩn đoán. Những trường hợp sử dụng này mô tả công việc trước tiên và tính năng giao thức sau.

Header HTTP, Thân, Cookie, và Tham số URL

Header HTTP thuộc về một lớp của HTTP và không nên nhầm lẫn với các lớp bên cạnh. Một triển khai hợp lý xác định thành phần nào chọn giá trị, thành phần nào có thể thay đổi nó, và bằng chứng gì chứng minh rằng đại diện cuối cùng là chính xác.

Một sự so sánh chỉ hữu ích nếu nó bảo tồn ranh giới lớp. Hai cơ chế có thể đồng thời tồn tại trong một yêu cầu, và việc thay thế một cái không tự động thay thế cái kia. Ghi nhận hành vi đã chọn theo cách của các đầu vào, đầu ra quan sát được, trạng thái thất bại, và quyền sở hữu.

Lỗi Xử lý Header cần Tránh

• Sao chép một tập header của trình duyệt một cách mù quáng. Các trường trình duyệt phản ánh một bối cảnh điều hướng và có thể không nhất quán khi được dán vào một khách hàng khác.
• Giả định rằng tên là phân biệt chữ hoa chữ thường. Các tên trường HTTP không phân biệt chữ hoa chữ thường mặc dù các công cụ có thể bảo tồn kiểu hiển thị.
• Chia tách mọi giá trị bằng dấu phẩy. Nhiều trường sử dụng ngữ pháp có cấu trúc, nơi văn bản được trích dẫn hoặc ngày tháng làm cho việc tách biệt đơn giản trở nên không an toàn.
• Thông tin đăng nhập. Giá trị ủy quyền và cookie có thể cấp quyền truy cập và cần được xóa bỏ khi nhập.
• Nhầm lẫn giữa Content-Type với Content-Encoding. Một cái xác định loại phương tiện; cái còn lại xác định các chuyển đổi được áp dụng cho các byte của nó.
• Chỉ tin tưởng vào một trạng thái. Một trạng thái thành công có thể mang theo một trang đồng ý bất ngờ, thử thách, hoặc đại diện thay thế.

Hầu hết các lỗi trở nên dễ chẩn đoán hơn sau khi loại bỏ các giả định về những gì thư viện hoặc trình duyệt đã làm tự động. Ghi lại một dấu vết tối thiểu, xóa bỏ bí mật, và thay đổi một biến có kiểm soát tại một thời điểm. Mục tiêu là có một lời giải thích ổn định về đại diện đã trả về, chứ không phải là một tập hợp các điều chỉnh tiêu đề không liên quan.

Một Quy Trình Kiểm Tra Tiêu Đề HTTP

Chuỗi này hoạt động như một đánh giá thiết kế trước khi ra mắt và như một chẩn đoán sản xuất sau khi hành vi thay đổi. Nó giữ bằng chứng giao thức liên kết với kết quả ứng dụng.

1. Ghi lại khách hàng, phiên bản HTTP, URL yêu cầu và URL cuối cùng trước khi so sánh các trường.
2. Tách biệt các trường yêu cầu và trường phản hồi và xóa bỏ giá trị xác thực hoặc cookie ngay lập tức.
3. Kiểm tra Content-Type trước khi phân tích nội dung và Content-Encoding trước khi giải mã các byte thô.
4. Xem lại các giá trị Location chuyển hướng và so sánh tiêu đề tại mỗi bước nhảy thay vì chỉ ở URL cuối cùng.
5. Kiểm tra Vary khi bộ nhớ cache trả về các đại diện khác nhau cho các URL dường như giống hệt nhau.
6. So sánh sự hiện diện và ý nghĩa của các trường, không phải thứ tự thẩm mỹ hoặc kiểu chữ được hiển thị bởi các công cụ phát triển.
7. Xác thực trang đã trả về với một tiêu đề, URL chuẩn, hoặc đánh dấu nội dung cần thiết sau khi các kiểm tra tiêu đề thông qua.

Hoàn thành việc xem xét bằng cách lưu mẫu chấp nhận nhỏ và mẫu bị từ chối với cùng quy tắc xóa bỏ. Những thay đổi trong tương lai có thể được so sánh với danh tính trang đã biết, các trường mong đợi, và nội dung đã giải mã thay vì chỉ dựa vào bộ nhớ hoặc ảnh chụp màn hình.

An ninh và Khả năng quan sát cho Tiêu Đề HTTP

Tiêu đề HTTP tham gia vào một đường dẫn yêu cầu có thể vượt qua các trình duyệt, cổng, bộ nhớ đệm và máy chủ gốc. Mỗi bước nhảy nên chỉ chấp nhận các giá trị mà nó hiểu, bảo tồn các trường cần tồn tại, và tránh sao chép thông tin đăng nhập hoặc dữ liệu cá nhân vào nhật ký. Cú pháp giao thức không phải là ủy quyền.

Các bản ghi hoạt động nên ghi lại URL yêu cầu, URL cuối cùng, trạng thái, loại đại diện, tên các trường có liên quan, và một dấu hiệu nội dung được giới hạn. Toàn bộ cơ thể và giá trị xác thực hiếm khi cần thiết cho chẩn đoán thông thường và có thể tạo ra rủi ro lưu giữ không cần thiết.

Hành vi của trình duyệt và hành vi HTTP trực tiếp là các bề mặt kiểm tra khác nhau. CORS, lưu trữ cookie, giải nén tự động, và xử lý chuyển hướng có thể được thực hiện bởi trình duyệt hoặc thư viện trước khi mã ứng dụng thấy kết quả. Ghi lại khách hàng và các mặc định của nó khi so sánh các ghi nhận.

Các tiêu chuẩn định nghĩa Tiêu Đề HTTP

các đặc tả ngữ nghĩa HTTP định nghĩa ngữ nghĩa và xử lý trường. Nguồn gốc chính này cố định từ vựng và ranh giới sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng và triển khai được chọn.

đăng ký trường HTTP IANA ghi lại tên trường tiêu chuẩn hóa. Nguồn gốc chính này cố định từ vựng và ranh giới sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng và triển khai được chọn.

đặc tả thông điệp HTTP/1.1 định nghĩa cú pháp thông điệp cho HTTP/1.1. Nguồn gốc chính này cố định từ vựng và ranh giới sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng và triển khai được chọn.

tham chiếu tiêu đề HTTP của MDN tổ chức các trường yêu cầu và phản hồi thường được triển khai. Nguồn gốc chính này cố định từ vựng và ranh giới sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng và triển khai được chọn.

Quy Tắc Đọc Tiêu Đề

Đọc từng tiêu đề HTTP theo định nghĩa trường của nó, giữ thông tin siêu dữ liệu vận chuyển tách biệt khỏi dữ liệu đại diện, và xác thực nội dung trước khi quyết định rằng một yêu cầu đã thành công.

Đưa quy tắc đó vào một bài kiểm tra chấp nhận. Nêu rõ bên nào gửi tín hiệu, bên nào diễn giải nó, các trung gian nào có thể thay đổi đường đi, và dấu hiệu nội dung nào chứng thực thành công. Điều này khiến Tiêu Đề HTTP trở thành một phần của hệ thống quan sát được chứ không phải là một nhãn gán sau khi xảy ra lỗi.

Tài liệu tham khảo

• Tài liệu API thu thập dữ liệu tổng quát không có phần dư
• Tổng quan sản phẩm API thu thập dữ liệu tổng quát không có phần dư
• Hướng dẫn Scrapeless về tiêu đề, cookie, phiên làm việc và xác thực đại diện
• Scrapeless trên GitHub