HTTP - คู่มือฉบับย่อ

Hypertext Transfer Protocol (HTTP) เป็นโปรโตคอลระดับแอปพลิเคชันสำหรับระบบข้อมูลแบบกระจายการทำงานร่วมกันและไฮเปอร์มีเดีย นี่เป็นรากฐานสำหรับการสื่อสารข้อมูลสำหรับเวิลด์ไวด์เว็บ (เช่นอินเทอร์เน็ต) ตั้งแต่ปี 1990 HTTP เป็นโปรโตคอลทั่วไปและไร้สัญชาติซึ่งสามารถใช้เพื่อวัตถุประสงค์อื่นได้เช่นกันโดยใช้ส่วนขยายของวิธีการร้องขอรหัสข้อผิดพลาดและส่วนหัว

โดยพื้นฐานแล้ว HTTP เป็นโปรโตคอลการสื่อสารที่ใช้ TCP / IP ซึ่งใช้ในการส่งข้อมูล (ไฟล์ HTML ไฟล์รูปภาพผลการสืบค้น ฯลฯ ) บนเวิลด์ไวด์เว็บ พอร์ตเริ่มต้นคือ TCP 80 แต่สามารถใช้พอร์ตอื่นได้ เป็นวิธีที่เป็นมาตรฐานสำหรับคอมพิวเตอร์ในการสื่อสารระหว่างกัน ข้อกำหนด HTTP ระบุวิธีสร้างและส่งข้อมูลคำขอของไคลเอ็นต์ไปยังการให้บริการและเซิร์ฟเวอร์ตอบสนองต่อคำขอเหล่านี้อย่างไร

คุณสมบัติพื้นฐาน

มีคุณสมบัติพื้นฐานสามประการดังต่อไปนี้ซึ่งทำให้ HTTP เป็นโปรโตคอลที่เรียบง่าย แต่ทรงพลัง:

HTTP is connectionless:ไคลเอนต์ HTTP เช่น เบราว์เซอร์เริ่มต้นคำขอ HTTP และหลังจากส่งคำขอไคลเอนต์จะยกเลิกการเชื่อมต่อจากเซิร์ฟเวอร์และรอการตอบกลับ เซิร์ฟเวอร์ประมวลผลคำขอและสร้างการเชื่อมต่อกับไคลเอ็นต์อีกครั้งเพื่อส่งการตอบกลับ
HTTP is media independent:ซึ่งหมายความว่า HTTP สามารถส่งข้อมูลประเภทใดก็ได้ตราบเท่าที่ทั้งไคลเอนต์และเซิร์ฟเวอร์รู้วิธีจัดการกับเนื้อหาข้อมูล สิ่งนี้จำเป็นสำหรับไคลเอนต์และเซิร์ฟเวอร์เพื่อระบุประเภทเนื้อหาโดยใช้ประเภท MIME ที่เหมาะสม
HTTP is stateless:ดังที่กล่าวไว้ข้างต้น HTTP เป็นแบบไร้การเชื่อมต่อและนี่เป็นผลโดยตรงที่ HTTP เป็นโปรโตคอลไร้สถานะ เซิร์ฟเวอร์และไคลเอนต์จะรับรู้ซึ่งกันและกันในระหว่างการร้องขอปัจจุบันเท่านั้น หลังจากนั้นทั้งคู่ก็ลืมเกี่ยวกับกันและกัน เนื่องจากลักษณะของโปรโตคอลนี้ทั้งไคลเอนต์และเบราว์เซอร์ไม่สามารถเก็บรักษาข้อมูลระหว่างคำขอต่างๆในหน้าเว็บได้

HTTP / 1.0 ใช้การเชื่อมต่อใหม่สำหรับการแลกเปลี่ยนคำขอ / การตอบกลับแต่ละรายการโดยที่อาจใช้การเชื่อมต่อ HTTP / 1.1 สำหรับการแลกเปลี่ยนคำขอ / การตอบกลับอย่างน้อยหนึ่งรายการ

สถาปัตยกรรมพื้นฐาน

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมพื้นฐานของเว็บแอปพลิเคชันและแสดงตำแหน่งที่ HTTP อยู่:

โปรโตคอล HTTP เป็นโปรโตคอลการร้องขอ / การตอบสนองตามสถาปัตยกรรมที่ใช้ไคลเอนต์ / เซิร์ฟเวอร์ซึ่งเว็บเบราว์เซอร์โรบ็อตและเครื่องมือค้นหา ฯลฯ ทำหน้าที่เหมือนไคลเอ็นต์ HTTP และเว็บเซิร์ฟเวอร์ทำหน้าที่เป็นเซิร์ฟเวอร์

ลูกค้า

ไคลเอ็นต์ HTTP ส่งคำขอไปยังเซิร์ฟเวอร์ในรูปแบบของวิธีการร้องขอ URI และเวอร์ชันโปรโตคอลตามด้วยข้อความคล้าย MIME ที่มีตัวปรับเปลี่ยนคำขอข้อมูลไคลเอ็นต์และเนื้อหาที่เป็นไปได้ผ่านการเชื่อมต่อ TCP / IP

เซิร์ฟเวอร์

เซิร์ฟเวอร์ HTTP ตอบสนองด้วยบรรทัดสถานะรวมถึงเวอร์ชันโปรโตคอลของข้อความและความสำเร็จหรือรหัสข้อผิดพลาดตามด้วยข้อความคล้าย MIME ที่มีข้อมูลเซิร์ฟเวอร์ข้อมูลเมตาเอนทิตีและเนื้อหาเอนทิตี - เนื้อหาที่เป็นไปได้

บทนี้จะแสดงรายการพารามิเตอร์ HTTP Protocol ที่สำคัญบางส่วนและไวยากรณ์ในลักษณะที่ใช้ในการสื่อสาร ตัวอย่างเช่นรูปแบบวันที่รูปแบบของ URL เป็นต้นซึ่งจะช่วยคุณในการสร้างคำขอและข้อความตอบกลับขณะเขียนโปรแกรมไคลเอ็นต์ HTTP หรือเซิร์ฟเวอร์ คุณจะเห็นการใช้พารามิเตอร์เหล่านี้อย่างสมบูรณ์ในบทต่อ ๆ ไปพร้อมกับอธิบายโครงสร้างข้อความสำหรับคำขอ HTTP และการตอบกลับ

เวอร์ชัน HTTP

HTTP ใช้ไฟล์ <major>.<minor>รูปแบบการกำหนดหมายเลขเพื่อระบุเวอร์ชันของโปรโตคอล เวอร์ชันของข้อความ HTTP ถูกระบุโดยฟิลด์เวอร์ชัน HTTP ในบรรทัดแรก นี่คือไวยากรณ์ทั่วไปของการระบุหมายเลขเวอร์ชัน HTTP:

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

ตัวอย่าง

HTTP/1.0

or

HTTP/1.1

Uniform Resource Identifiers (URI)

Uniform Resource Identifiers (URI) มีการจัดรูปแบบเพียงสตริงที่ไม่คำนึงถึงขนาดตัวพิมพ์ที่มีชื่อตำแหน่งที่ตั้งและอื่น ๆ เพื่อระบุทรัพยากรเช่นเว็บไซต์บริการเว็บเป็นต้นไวยากรณ์ทั่วไปของ URI ที่ใช้สำหรับ HTTP มีดังนี้:

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

ที่นี่ถ้า port ว่างเปล่าหรือไม่ได้กำหนดพอร์ต 80 จะถือว่าเป็น HTTP และเป็นช่องว่าง abs_path เทียบเท่ากับไฟล์ abs_pathของ "/". อักขระอื่นที่ไม่ใช่ในไฟล์reserved และ unsafe ชุดเทียบเท่ากับการเข้ารหัส "%" HEX HEX "

ตัวอย่าง

URI สองรายการต่อไปนี้เทียบเท่า:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

รูปแบบวันที่ / เวลา

การประทับวันที่ / เวลา HTTP ทั้งหมดต้องแสดงเป็นเวลามาตรฐานกรีนิช (GMT) โดยไม่มีข้อยกเว้น แอปพลิเคชัน HTTP ได้รับอนุญาตให้ใช้การแสดงวันที่ / เวลาสามรายการต่อไปนี้:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

ชุดอักขระ

คุณใช้ชุดอักขระเพื่อระบุชุดอักขระที่ไคลเอ็นต์ต้องการ ชุดอักขระหลายชุดสามารถแสดงรายการโดยคั่นด้วยเครื่องหมายจุลภาค หากไม่ได้ระบุค่าไว้ค่าเริ่มต้นคือ US-ASCII

ตัวอย่าง

ต่อไปนี้เป็นชุดอักขระที่ถูกต้อง:

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

การเข้ารหัสเนื้อหา

ค่าการถอดรหัสเนื้อหาระบุว่ามีการใช้อัลกอริทึมการเข้ารหัสเพื่อเข้ารหัสเนื้อหาก่อนที่จะส่งผ่านเครือข่าย การเข้ารหัสเนื้อหาส่วนใหญ่ใช้เพื่ออนุญาตให้บีบอัดเอกสารหรือเปลี่ยนรูปแบบให้เป็นประโยชน์โดยไม่สูญเสียข้อมูลประจำตัว

ค่าการเข้ารหัสเนื้อหาทั้งหมดไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่ HTTP / 1.1 ใช้ค่าการเข้ารหัสเนื้อหาในฟิลด์ส่วนหัวที่ยอมรับการเข้ารหัสและการเข้ารหัสเนื้อหาซึ่งเราจะเห็นในบทต่อ ๆ ไป

ตัวอย่าง

ต่อไปนี้เป็นรูปแบบการเข้ารหัสที่ถูกต้อง:

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

ประเภทสื่อ

HTTP ใช้ประเภทสื่ออินเทอร์เน็ตในไฟล์ Content-Type และ Acceptฟิลด์ส่วนหัวเพื่อจัดเตรียมการพิมพ์และการต่อรองประเภทข้อมูลแบบเปิดและขยายได้ ค่าประเภทสื่อทั้งหมดจะลงทะเบียนกับ Internet Assigned Number Authority ((IANA) ต่อไปนี้เป็นไวยากรณ์ทั่วไปสำหรับระบุประเภทสื่อ:

media-type     = type "/" subtype *( ";" parameter )

ชื่อแอ็ตทริบิวต์ชนิดชนิดย่อยและพารามิเตอร์ไม่คำนึงถึงขนาดตัวพิมพ์

ตัวอย่าง

Accept: image/gif

แท็กภาษา

HTTP ใช้แท็กภาษาภายในไฟล์ Accept-Language และ Content-Languageฟิลด์ แท็กภาษาประกอบด้วย 1 ส่วนหรือมากกว่า: แท็กภาษาหลักและแท็กย่อยที่อาจว่างเปล่า:

language-tag  = primary-tag *( "-" subtag )

ไม่อนุญาตให้มีช่องว่างภายในแท็กและแท็กทั้งหมดไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่

ตัวอย่าง

ตัวอย่างแท็ก ได้แก่ :

en, en-US, en-cockney, i-cherokee, x-pig-latin

โดยที่แท็กหลักสองตัวอักษรเป็นตัวย่อภาษา ISO-639 และแท็กย่อยเริ่มต้นสองตัวอักษรคือรหัสประเทศ ISO-3166

HTTP ขึ้นอยู่กับรูปแบบสถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์และโปรโตคอลการร้องขอ / ตอบกลับแบบไม่ระบุสถานะที่ทำงานโดยการแลกเปลี่ยนข้อความผ่านการเชื่อมต่อ TCP / IP ที่เชื่อถือได้

"ไคลเอนต์" HTTP คือโปรแกรม (เว็บเบราว์เซอร์หรือไคลเอนต์อื่น ๆ ) ที่สร้างการเชื่อมต่อกับเซิร์ฟเวอร์เพื่อวัตถุประสงค์ในการส่งข้อความคำขอ HTTP อย่างน้อยหนึ่งข้อความ "เซิร์ฟเวอร์" HTTP คือโปรแกรม (โดยทั่วไปคือเว็บเซิร์ฟเวอร์เช่น Apache Web Server หรือ Internet Information Services IIS เป็นต้น) ที่ยอมรับการเชื่อมต่อเพื่อให้บริการคำขอ HTTP โดยการส่งข้อความตอบกลับ HTTP

HTTP ใช้ประโยชน์จาก Uniform Resource Identifier (URI) เพื่อระบุทรัพยากรที่กำหนดและสร้างการเชื่อมต่อ เมื่อสร้างการเชื่อมต่อแล้วHTTP messagesจะถูกส่งผ่านในรูปแบบที่คล้ายคลึงกับอินเทอร์เน็ตเมล [RFC5322] และ Multipurpose Internet Mail Extensions (MIME) [RFC2045] ข้อความเหล่านี้ประกอบด้วยrequests จากไคลเอนต์ไปยังเซิร์ฟเวอร์และ responses จากเซิร์ฟเวอร์ไปยังไคลเอนต์ซึ่งจะมีรูปแบบดังนี้:

HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

คำขอ HTTP และการตอบกลับ HTTP ใช้รูปแบบข้อความทั่วไปของ RFC 822 สำหรับการถ่ายโอนข้อมูลที่ต้องการ รูปแบบข้อความทั่วไปนี้ประกอบด้วยสี่รายการต่อไปนี้


     
      A Start-line
 Zero or more header fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

ส่วนต่อไปนี้จะอธิบายแต่ละเอนทิตีที่ใช้ในข้อความ HTTP

ข้อความเริ่มบรรทัด

บรรทัดเริ่มต้นจะมีไวยากรณ์ทั่วไปดังต่อไปนี้:

start-line = Request-Line | Status-Line

เราจะพูดคุยเกี่ยวกับ Request-Line และ Status-Line ในขณะที่พูดคุยเกี่ยวกับคำขอ HTTP และข้อความตอบกลับ HTTP ตามลำดับ ตอนนี้เรามาดูตัวอย่างของบรรทัดเริ่มต้นในกรณีของการร้องขอและการตอบสนอง:

GET /hello.htm HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

ฟิลด์ส่วนหัว

ฟิลด์ตัวตายของ HTTP ให้ข้อมูลที่จำเป็นเกี่ยวกับคำขอหรือการตอบกลับหรือเกี่ยวกับออบเจ็กต์ที่ส่งในเนื้อหาข้อความ ส่วนหัวข้อความ HTTP มีสี่ประเภทดังต่อไปนี้:

General-header: ฟิลด์ส่วนหัวเหล่านี้มีการบังคับใช้ทั่วไปสำหรับทั้งข้อความร้องขอและข้อความตอบกลับ
Request-header: ช่องส่วนหัวเหล่านี้ใช้สำหรับข้อความร้องขอเท่านั้น
Response-header: ช่องส่วนหัวเหล่านี้สามารถใช้ได้กับข้อความตอบกลับเท่านั้น
Entity-header: ฟิลด์ส่วนหัวเหล่านี้กำหนดข้อมูลเมตาเกี่ยวกับเอนทิตี - ร่างกายหรือหากไม่มีเนื้อหา

ส่วนหัวที่กล่าวถึงข้างต้นทั้งหมดเป็นไปตามรูปแบบทั่วไปเดียวกันและแต่ละฟิลด์ส่วนหัวประกอบด้วยชื่อตามด้วยเครื่องหมายจุดคู่ (:) และค่าฟิลด์ดังนี้:

message-header = field-name ":" [ field-value ]

ต่อไปนี้เป็นตัวอย่างของฟิลด์ส่วนหัวต่างๆ:

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

เนื้อหาข้อความ

ส่วนเนื้อหาของข้อความเป็นทางเลือกสำหรับข้อความ HTTP แต่ถ้าพร้อมใช้งานจะใช้เพื่อนำเอนทิตี - เนื้อหาที่เกี่ยวข้องกับคำขอหรือการตอบกลับ หากมีการเชื่อมโยงร่างกายของเอนทิตีมักจะContent-Type และ Content-Length บรรทัดส่วนหัวระบุลักษณะของเนื้อหาที่เกี่ยวข้อง

เนื้อหาข้อความคือเนื้อหาที่มีข้อมูลคำขอ HTTP จริง (รวมถึงข้อมูลแบบฟอร์มและอัปโหลดเป็นต้น) และข้อมูลตอบกลับ HTTP จากเซิร์ฟเวอร์ (รวมถึงไฟล์รูปภาพ ฯลฯ ) ต่อไปนี้เป็นเนื้อหาง่ายๆของเนื้อหาข้อความ:

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

ไคลเอนต์ HTTP ส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์ในรูปแบบของข้อความร้องขอซึ่งรวมถึงรูปแบบต่อไปนี้:


     
      A Request-line
 Zero or more header (General|Request|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

ส่วนต่อไปนี้จะอธิบายแต่ละเอนทิตีที่ใช้ในข้อความ HTTP

ขอข้อความ - Line

Request-Line เริ่มต้นด้วยโทเค็นวิธีการตามด้วย Request-URI และเวอร์ชันโปรโตคอลและลงท้ายด้วย CRLF องค์ประกอบจะถูกคั่นด้วยอักขระ SP เว้นวรรค

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

มาพูดถึงแต่ละส่วนที่กล่าวถึงใน Request-Line

วิธีการขอ

คำขอ Method ระบุวิธีการที่จะดำเนินการกับทรัพยากรที่ระบุโดยที่กำหนด Request-URI. วิธีนี้คำนึงถึงตัวพิมพ์เล็กและใหญ่ ans ควรกล่าวถึงตัวพิมพ์ใหญ่เสมอ ต่อไปนี้เป็นวิธีการที่รองรับใน HTTP / 1.1

SN	วิธีการและคำอธิบาย
1	GET เมธอด GET ใช้เพื่อดึงข้อมูลจากเซิร์ฟเวอร์ที่กำหนดโดยใช้ URI ที่กำหนด คำขอที่ใช้ GET ควรดึงข้อมูลเท่านั้นและไม่ควรมีผลกระทบอื่นใดกับข้อมูล
2	HEAD เหมือนกับ GET แต่โอนเฉพาะบรรทัดสถานะและส่วนหัวเท่านั้น
3	POST คำขอ POST ใช้เพื่อส่งข้อมูลไปยังเซิร์ฟเวอร์ตัวอย่างเช่นข้อมูลลูกค้าการอัปโหลดไฟล์ ฯลฯ โดยใช้แบบฟอร์ม HTML
4	PUT แทนที่การนำเสนอปัจจุบันทั้งหมดของทรัพยากรเป้าหมายด้วยเนื้อหาที่อัปโหลด
5	DELETE ลบการแสดงปัจจุบันทั้งหมดของทรัพยากรเป้าหมายที่กำหนดโดย URI
6	CONNECT สร้างอุโมงค์ไปยังเซิร์ฟเวอร์ที่ระบุโดย URI ที่กำหนด
7	OPTIONS อธิบายตัวเลือกการสื่อสารสำหรับทรัพยากรเป้าหมาย
8	TRACE ทำการทดสอบข้อความวนกลับไปตามเส้นทางไปยังทรัพยากรเป้าหมาย

คำขอ -URI

Request-URI เป็น Uniform Resource Identifier และระบุทรัพยากรที่จะใช้คำขอ ต่อไปนี้เป็นแบบฟอร์มที่ใช้บ่อยที่สุดในการระบุ URI:

Request-URI = "*" | absoluteURI | abs_path | authority

SN	วิธีการและคำอธิบาย
1	เครื่องหมายดอกจัน ใช้เมื่อคำขอ HTTP ไม่ได้ใช้กับทรัพยากรใดทรัพยากรหนึ่ง แต่ใช้กับเซิร์ฟเวอร์เองและได้รับอนุญาตก็ต่อเมื่อวิธีการที่ใช้ไม่จำเป็นต้องใช้กับทรัพยากร ตัวอย่างเช่น: OPTIONS HTTP/1.1**
2	absoluteURIใช้เมื่อมีการร้องขอ HTTP ไปยังพร็อกซี พร็อกซีถูกร้องขอเพื่อส่งต่อคำขอหรือให้บริการจากแคชที่ถูกต้องและส่งคืนการตอบกลับ ตัวอย่างเช่น: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3	รูปแบบที่พบบ่อยที่สุดของ Request-URI คือที่ใช้เพื่อระบุทรัพยากรบนเซิร์ฟเวอร์ต้นทางหรือเกตเวย์ ตัวอย่างเช่นไคลเอนต์ที่ต้องการดึงทรัพยากรข้างต้นโดยตรงจากเซิร์ฟเวอร์ต้นทางจะสร้างการเชื่อมต่อ TCP ไปยังพอร์ต 80 ของโฮสต์ "www.w3.org" และส่งบรรทัด: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org โปรดทราบว่าเส้นทางสัมบูรณ์ต้องไม่ว่างเปล่า หากไม่มีอยู่ใน URI ดั้งเดิมจะต้องกำหนดเป็น "/" (รูทเซิร์ฟเวอร์)

ขอฟิลด์ส่วนหัว

เราจะศึกษา General-header และ Entity-header ในบทที่แยกต่างหากเมื่อเราจะเรียนรู้ฟิลด์ส่วนหัว HTTP ตอนนี้เรามาตรวจสอบว่าฟิลด์ส่วนหัวของคำขอคืออะไร

ฟิลด์ส่วนหัวของคำร้องขออนุญาตให้ไคลเอ็นต์ส่งข้อมูลเพิ่มเติมเกี่ยวกับคำร้องขอและเกี่ยวกับไคลเอนต์ไปยังเซิร์ฟเวอร์ ฟิลด์เหล่านี้ทำหน้าที่เป็นตัวปรับเปลี่ยนคำขอและมีฟิลด์ส่วนหัวคำขอที่สำคัญต่อไปนี้ซึ่งสามารถใช้ได้ตามความต้องการ

Accept-Charset
Accept-Encoding
Accept-Language
Authorization
Expect
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range
Referer
TE
User-Agent

คุณสามารถแนะนำฟิลด์ที่กำหนดเองของคุณในกรณีที่คุณกำลังจะเขียนไคลเอ็นต์และเว็บเซิร์ฟเวอร์ที่กำหนดเองของคุณเอง

ขอตัวอย่างข้อความ

ตอนนี้มารวมกันเพื่อสร้างคำขอ HTTP เพื่อดึงข้อมูล hello.htm จากเว็บเซิร์ฟเวอร์ที่ทำงานบน tutorialspoint.com

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

ที่นี่เราไม่ได้ส่งข้อมูลคำขอใด ๆ ไปยังเซิร์ฟเวอร์เนื่องจากเรากำลังดึงหน้าแผน HTML จากเซิร์ฟเวอร์ การเชื่อมต่อเป็นส่วนหัวทั่วไปที่ใช้ที่นี่และส่วนหัวที่เหลือเป็นส่วนหัวของคำขอ ต่อไปนี้เป็นอีกหนึ่งตัวอย่างที่เราส่งข้อมูลแบบฟอร์มไปยังเซิร์ฟเวอร์โดยใช้เนื้อหาข้อความคำขอ:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

URL ที่ระบุที่นี่/cgi-bin/process.cgiจะถูกใช้เพื่อประมวลผลข้อมูลที่ส่งผ่านและการตอบกลับจะถูกเรียกใช้ใหม่ ที่นี่content-type บอกเซิร์ฟเวอร์ที่ส่งผ่านข้อมูลเป็นข้อมูลฟอร์มบนเว็บอย่างง่ายและ lengthจะเป็นความยาวจริงของข้อมูลที่ใส่ในเนื้อหาข้อความ ตัวอย่างต่อไปนี้แสดงวิธีที่คุณสามารถส่งแผน XML ไปยังเว็บเซิร์ฟเวอร์ของคุณ:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

หลังจากรับและตีความข้อความร้องขอเซิร์ฟเวอร์จะตอบกลับด้วยข้อความตอบกลับ HTTP:


     
      A Status-line
 Zero or more header (General|Response|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

ส่วนต่อไปนี้จะอธิบายแต่ละเอนทิตีที่ใช้ในข้อความ HTTP

สถานะข้อความ - บรรทัด

Status-Line ประกอบด้วยเวอร์ชันโปรโตคอลตามด้วยรหัสสถานะตัวเลขและข้อความที่เกี่ยวข้อง องค์ประกอบจะถูกคั่นด้วยอักขระ SP เว้นวรรค

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

มาพูดถึงแต่ละส่วนที่กล่าวถึงใน Status-Line

เวอร์ชัน HTTP

เซิร์ฟเวอร์ที่รองรับ HTTP เวอร์ชัน 1.1 จะส่งคืนข้อมูลเวอร์ชันต่อไปนี้:

HTTP-Version = HTTP/1.1

รหัสสถานะ

องค์ประกอบ Status-Code คือจำนวนเต็ม 3 หลักโดยที่ตัวเลขตัวแรกของ Status-Code กำหนดคลาสของการตอบกลับและตัวเลขสองหลักสุดท้ายไม่มีบทบาทในการจัดหมวดหมู่ มี 5 ค่าสำหรับหลักแรก:

SN	รหัสและคำอธิบาย
1	1xx: Informational ซึ่งหมายความว่าได้รับคำขอแล้วและดำเนินการต่อไป
2	2xx: Success ซึ่งหมายความว่าการดำเนินการได้รับการยอมรับเข้าใจและยอมรับเรียบร้อยแล้ว
3	3xx: Redirection ซึ่งหมายความว่าจะต้องดำเนินการเพิ่มเติมเพื่อดำเนินการตามคำขอ
4	4xx: Client Error ซึ่งหมายความว่าคำขอมีไวยากรณ์ที่ไม่ถูกต้องหรือไม่สามารถตอบสนองได้
5	5xx: Server Error เซิร์ฟเวอร์ไม่สามารถดำเนินการตามคำขอที่ถูกต้องชัดเจน

รหัสสถานะ HTTP สามารถขยายได้และแอปพลิเคชัน HTTP ไม่จำเป็นต้องเข้าใจความหมายของรหัสสถานะที่ลงทะเบียนทั้งหมด รายการรหัสสถานะทั้งหมดได้รับในบทที่แยกต่างหากเพื่อให้คุณอ้างอิง

ฟิลด์ส่วนหัวการตอบกลับ

เราจะศึกษา General-header และ Entity-header ในบทที่แยกต่างหากเมื่อเราจะเรียนรู้ฟิลด์ส่วนหัว HTTP ตอนนี้เรามาตรวจสอบว่าฟิลด์ส่วนหัวการตอบกลับคืออะไร

ฟิลด์ส่วนหัวการตอบกลับอนุญาตให้เซิร์ฟเวอร์ส่งข้อมูลเพิ่มเติมเกี่ยวกับการตอบสนองซึ่งไม่สามารถวางไว้ในบรรทัดสถานะ ฟิลด์ส่วนหัวเหล่านี้ให้ข้อมูลเกี่ยวกับเซิร์ฟเวอร์และเกี่ยวกับการเข้าถึงทรัพยากรเพิ่มเติมที่ระบุโดย Request-URI

Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate

คุณสามารถแนะนำฟิลด์ที่กำหนดเองของคุณในกรณีที่คุณกำลังจะเขียนเว็บไคลเอ็นต์และเซิร์ฟเวอร์ของคุณเอง

ตัวอย่างข้อความตอบกลับ

ทีนี้มารวมกันเพื่อสร้างการตอบสนอง HTTP สำหรับคำขอในการดึงข้อมูล hello.htm จากเว็บเซิร์ฟเวอร์ที่ทำงานบน tutorialspoint.com

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

ต่อไปนี้เป็นตัวอย่างของข้อความตอบกลับ HTTP ที่แสดงเงื่อนไขข้อผิดพลาดเมื่อเว็บเซิร์ฟเวอร์ไม่พบหน้าที่ร้องขอ:

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

ต่อไปนี้เป็นตัวอย่างของข้อความตอบกลับ HTTP ที่แสดงเงื่อนไขข้อผิดพลาดเมื่อเว็บเซิร์ฟเวอร์พบเวอร์ชัน HTTP ที่ไม่ถูกต้องในคำขอ HTTP ที่ระบุ:

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

ชุดวิธีการทั่วไปสำหรับ HTTP / 1.1 ถูกกำหนดไว้ด้านล่างและชุดนี้สามารถขยายได้ตามความต้องการ ชื่อเมธอดเหล่านี้คำนึงถึงตัวพิมพ์เล็กและใหญ่และต้องใช้เป็นตัวพิมพ์ใหญ่

SN	วิธีการและคำอธิบาย
1	GET เมธอด GET ใช้เพื่อดึงข้อมูลจากเซิร์ฟเวอร์ที่กำหนดโดยใช้ URI ที่กำหนด คำขอที่ใช้ GET ควรดึงข้อมูลเท่านั้นและไม่ควรมีผลกระทบอื่นใดกับข้อมูล
2	HEAD เหมือนกับ GET แต่โอนเฉพาะบรรทัดสถานะและส่วนหัวเท่านั้น
3	POST คำขอ POST ใช้เพื่อส่งข้อมูลไปยังเซิร์ฟเวอร์ตัวอย่างเช่นข้อมูลลูกค้าการอัปโหลดไฟล์ ฯลฯ โดยใช้แบบฟอร์ม HTML
4	PUT แทนที่การนำเสนอปัจจุบันทั้งหมดของทรัพยากรเป้าหมายด้วยเนื้อหาที่อัปโหลด
5	DELETE ลบการแสดงปัจจุบันทั้งหมดของทรัพยากรเป้าหมายที่กำหนดโดย URI
6	CONNECT สร้างอุโมงค์ไปยังเซิร์ฟเวอร์ที่ระบุโดย URI ที่กำหนด
7	OPTIONS อธิบายตัวเลือกการสื่อสารสำหรับทรัพยากรเป้าหมาย
8	TRACE ทำการทดสอบข้อความวนกลับไปตามเส้นทางไปยังทรัพยากรเป้าหมาย

รับวิธีการ

คำขอ GET ดึงข้อมูลจากเว็บเซิร์ฟเวอร์โดยระบุพารามิเตอร์ในส่วน URL ของคำขอ นี่เป็นวิธีหลักที่ใช้ในการดึงเอกสาร ต่อไปนี้เป็นตัวอย่างง่ายๆที่ใช้เมธอด GET เพื่อดึงข้อมูล hello.htm:

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

ต่อไปนี้จะเป็นการตอบสนองของเซิร์ฟเวอร์ต่อคำขอ GET ข้างต้น:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

วิธีการหัว

เมธอด HEAD มีหน้าที่เหมือนกับ GET ยกเว้นว่าเซิร์ฟเวอร์ตอบกลับด้วยบรรทัดตอบกลับและส่วนหัว แต่ไม่มีเอนทิตี - เนื้อหา ต่อไปนี้เป็นตัวอย่างง่ายๆที่ใช้เมธอด HEAD เพื่อดึงข้อมูลส่วนหัวเกี่ยวกับ hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

ต่อไปนี้จะเป็นการตอบสนองของเซิร์ฟเวอร์ต่อคำขอ GET ข้างต้น:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

คุณสามารถสังเกตได้ว่าที่นี่เซิร์ฟเวอร์ไม่ส่งข้อมูลใด ๆ หลังส่วนหัว

วิธีการโพสต์

วิธีการ POST ใช้เมื่อคุณต้องการส่งข้อมูลบางส่วนไปยังเซิร์ฟเวอร์เช่นการอัปเดตไฟล์ข้อมูลแบบฟอร์มเป็นต้นต่อไปนี้เป็นตัวอย่างง่ายๆที่ใช้วิธีการ POST เพื่อส่งข้อมูลแบบฟอร์มไปยังเซิร์ฟเวอร์ซึ่งจะประมวลผลโดย a process.cgi และสุดท้ายการตอบกลับจะถูกส่งกลับ:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

สคริปต์ฝั่งเซิร์ฟเวอร์ process.cgi ประมวลผลข้อมูลที่ส่งผ่านและส่งการตอบสนองต่อไปนี้:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

วิธีการวาง

เมธอด PUT ใช้เพื่อขอให้เซิร์ฟเวอร์จัดเก็บเอนทิตี - บอดี้ที่รวมไว้ในตำแหน่งที่ระบุโดย URL ที่กำหนด เซิร์ฟเวอร์ร้องขอตัวอย่างต่อไปนี้เพื่อบันทึกเนื้อหาของเอนทิตีที่กำหนดในhello.htm ที่รากของเซิร์ฟเวอร์:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

เซิร์ฟเวอร์จะจัดเก็บเนื้อหาเอนทิตีที่กำหนดไว้ใน hello.htm ไฟล์และจะส่งการตอบกลับต่อไปนี้กลับไปยังไคลเอนต์:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

วิธีการลบ

เมธอด DELETE ใช้เพื่อขอให้เซิร์ฟเวอร์ลบไฟล์ในตำแหน่งที่ระบุโดย URL ที่กำหนด ตัวอย่างต่อไปนี้ขอเซิร์ฟเวอร์เพื่อลบไฟล์ที่กำหนดhello.htm ที่รากของเซิร์ฟเวอร์:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

เซิร์ฟเวอร์จะลบไฟล์ที่กล่าวถึง hello.htm และจะส่งคำตอบกลับไปยังไคลเอนต์:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

วิธีการเชื่อมต่อ

ไคลเอนต์ใช้เมธอด CONNECT เพื่อสร้างการเชื่อมต่อเครือข่ายกับเว็บเซิร์ฟเวอร์ผ่าน HTTP ตัวอย่างต่อไปนี้ร้องขอการเชื่อมต่อกับเว็บเซิร์ฟเวอร์ที่รันบนโฮสต์ tutorialspoint.com:

CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

การเชื่อมต่อถูกสร้างขึ้นกับเซิร์ฟเวอร์และการตอบสนองต่อไปนี้จะถูกส่งกลับไปยังไคลเอนต์:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

วิธี OPTIONS

ไคลเอนต์ใช้เมธอด OPTIONS เพื่อค้นหาว่าอะไรคือเมธอด HTTP และตัวเลือกอื่น ๆ ที่เว็บเซิร์ฟเวอร์รองรับ ไคลเอนต์สามารถระบุ URL สำหรับเมธอด OPTIONS หรือเครื่องหมายดอกจัน (*) เพื่ออ้างถึงเซิร์ฟเวอร์ทั้งหมด ตัวอย่างต่อไปนี้ขอรายการวิธีการที่สนับสนุนโดยเว็บเซิร์ฟเวอร์ที่รันบน tutorialspoint.com:

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

เซิร์ฟเวอร์จะส่งข้อมูลตามการกำหนดค่าปัจจุบันของเซิร์ฟเวอร์ตัวอย่างเช่น:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

วิธีการติดตาม

เมธอด TRACE ใช้เพื่อกำหนดเนื้อหาของคำขอ HTTP กลับไปยังผู้ร้องขอซึ่งสามารถใช้เพื่อวัตถุประสงค์ในการดีบักในขณะที่พัฒนา ตัวอย่างต่อไปนี้แสดงการใช้วิธี TRACE:

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

เซิร์ฟเวอร์จะส่งข้อความต่อไปนี้เพื่อตอบสนองคำขอข้างต้น:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

อิลิเมนต์ Status-Code ในการตอบกลับของเซิร์ฟเวอร์คือจำนวนเต็ม 3 หลักโดยที่ตัวเลขตัวแรกของ Status-Code จะกำหนดคลาสของการตอบสนองและตัวเลขสองหลักสุดท้ายไม่มีบทบาทในการจัดหมวดหมู่ มี 5 ค่าสำหรับหลักแรก:

SN	รหัสและคำอธิบาย
1	1xx: Informational ซึ่งหมายความว่าได้รับคำขอแล้วและดำเนินการต่อไป
2	2xx: Success ซึ่งหมายความว่าการดำเนินการได้รับการยอมรับเข้าใจและยอมรับเรียบร้อยแล้ว
3	3xx: Redirection ซึ่งหมายความว่าจะต้องดำเนินการเพิ่มเติมเพื่อดำเนินการตามคำขอ
4	4xx: Client Error ซึ่งหมายความว่าคำขอมีไวยากรณ์ที่ไม่ถูกต้องหรือไม่สามารถตอบสนองได้
5	5xx: Server Error เซิร์ฟเวอร์ไม่สามารถดำเนินการตามคำขอที่ถูกต้องชัดเจน

รหัสสถานะ HTTP สามารถขยายได้และแอปพลิเคชัน HTTP ไม่จำเป็นต้องเข้าใจความหมายของรหัสสถานะที่ลงทะเบียนทั้งหมด ต่อไปนี้เป็นรายการรหัสสถานะทั้งหมด

1xx: ข้อมูล

ข้อความ:	คำอธิบาย:
100 ดำเนินการต่อ	เซิร์ฟเวอร์ได้รับคำขอเพียงบางส่วนเท่านั้น แต่ตราบใดที่ยังไม่ถูกปฏิเสธไคลเอ็นต์ควรดำเนินการตามคำขอต่อไป
101 การสลับโปรโตคอล	เซิร์ฟเวอร์สลับโปรโตคอล

2xx: สำเร็จแล้ว

ข้อความ:	คำอธิบาย:
200 ตกลง	คำขอก็โอเค
201 สร้าง	คำขอเสร็จสมบูรณ์และมีการสร้างทรัพยากรใหม่
202 ยอมรับ	คำขอได้รับการยอมรับสำหรับการประมวลผล แต่การประมวลผลไม่สมบูรณ์
203 ข้อมูลที่ไม่น่าเชื่อถือ	ข้อมูลในส่วนหัวของเอนทิตีมาจากสำเนาในเครื่องหรือของบุคคลที่สามไม่ใช่จากเซิร์ฟเวอร์ดั้งเดิม
204 ไม่มีเนื้อหา	มีการระบุรหัสสถานะและส่วนหัวในการตอบกลับ แต่ไม่มีเนื้อความในการตอบกลับ
205 รีเซ็ตเนื้อหา	เบราว์เซอร์ควรล้างแบบฟอร์มที่ใช้สำหรับธุรกรรมนี้เพื่อป้อนข้อมูลเพิ่มเติม
206 เนื้อหาบางส่วน	เซิร์ฟเวอร์กำลังส่งคืนข้อมูลบางส่วนของขนาดที่ร้องขอ ใช้เพื่อตอบสนองคำขอที่ระบุส่วนหัวของช่วง เซิร์ฟเวอร์ต้องระบุช่วงที่รวมอยู่ในการตอบกลับด้วยส่วนหัวContent-Range

3xx: การเปลี่ยนเส้นทาง

ข้อความ:	คำอธิบาย:
300 หลายทางเลือก	ลิงค์ลิสต์ ผู้ใช้สามารถเลือกลิงค์และไปที่ตำแหน่งนั้นได้ สูงสุดห้าที่อยู่
301 ย้ายถาวร	หน้าที่ร้องขอได้ย้ายไปยัง URL ใหม่
พบ 302	หน้าที่ร้องขอได้ย้ายไปยัง URL ใหม่ชั่วคราว
303 ดูอื่น ๆ	หน้าที่ร้องขอสามารถพบได้ภายใต้ URL อื่น
304 ไม่ได้แก้ไข	นี่คือรหัสตอบกลับของส่วนหัวIf-Modified-SinceหรือIf-None-Matchโดยที่ URL ไม่ได้รับการแก้ไขตั้งแต่วันที่ที่ระบุ
305 ใช้ Proxy	ต้องเข้าถึง URL ที่ร้องขอผ่านพร็อกซีที่กล่าวถึงในส่วนหัวตำแหน่ง
306 ไม่ได้ใช้	รหัสนี้ถูกใช้ในเวอร์ชันก่อนหน้า ไม่มีการใช้งานอีกต่อไป แต่สงวนรหัสไว้
307 การเปลี่ยนเส้นทางชั่วคราว	หน้าที่ร้องขอได้ย้ายไปยัง URL ใหม่ชั่วคราว

4xx: ข้อผิดพลาดของไคลเอ็นต์

ข้อความ:	คำอธิบาย:
400 คำขอที่ไม่ถูกต้อง	เซิร์ฟเวอร์ไม่เข้าใจคำขอ
401 ไม่ได้รับอนุญาต	หน้าที่ร้องขอต้องมีชื่อผู้ใช้และรหัสผ่าน
402 ต้องชำระเงิน	คุณยังไม่สามารถใช้รหัสนี้ได้
403 ต้องห้าม	ไม่อนุญาตให้เข้าถึงหน้าที่ร้องขอ
404 ไม่พบ	เซิร์ฟเวอร์ไม่พบหน้าที่ร้องขอ
ไม่อนุญาตวิธี 405	ไม่อนุญาตวิธีการที่ระบุในคำขอ
406 ไม่ยอมรับ	เซิร์ฟเวอร์สามารถสร้างการตอบสนองที่ไคลเอนต์ไม่ยอมรับเท่านั้น
ต้องมีการพิสูจน์ตัวตน 407 พร็อกซี	คุณต้องตรวจสอบสิทธิ์กับพร็อกซีเซิร์ฟเวอร์ก่อนจึงจะสามารถให้บริการได้
408 ขอหมดเวลา	คำขอใช้เวลานานกว่าที่เซิร์ฟเวอร์เตรียมรอ
409 ความขัดแย้ง	ไม่สามารถดำเนินการตามคำขอได้เนื่องจากมีข้อขัดแย้ง
410 หายไป	หน้าที่ร้องขอไม่สามารถใช้ได้อีกต่อไป
411 ความยาวที่ต้องการ	ไม่ได้กำหนด "ความยาวของเนื้อหา" เซิร์ฟเวอร์จะไม่ยอมรับคำขอหากไม่มีมัน
412 เงื่อนไขเบื้องต้นล้มเหลว	เงื่อนไขเบื้องต้นที่กำหนดในคำขอที่เซิร์ฟเวอร์ประเมินเป็นเท็จ
413 ขอเอนทิตีใหญ่เกินไป	เซิร์ฟเวอร์จะไม่ยอมรับคำขอเนื่องจากเอนทิตีคำขอมีขนาดใหญ่เกินไป
414 Request-url ยาวเกินไป	เซิร์ฟเวอร์จะไม่ยอมรับคำขอเนื่องจาก url ยาวเกินไป เกิดขึ้นเมื่อคุณแปลงคำขอ "โพสต์" เป็นคำขอ "รับ" ด้วยข้อมูลการสืบค้นแบบยาว
415 ประเภทสื่อที่ไม่รองรับ	เซิร์ฟเวอร์จะไม่ยอมรับคำขอเนื่องจากไม่รองรับประเภทสื่อ
416 ช่วงที่ร้องขอไม่น่าพอใจ	ช่วงไบต์ที่ร้องขอไม่พร้อมใช้งานและอยู่นอกขอบเขต
417 ความคาดหวังล้มเหลว	เซิร์ฟเวอร์นี้ไม่สามารถตอบสนองความคาดหวังที่ระบุในฟิลด์ส่วนหัวของคำขอ Expect

5xx: ข้อผิดพลาดของเซิร์ฟเวอร์

ข้อความ:	คำอธิบาย:
500 ข้อผิดพลาดภายในเซิร์ฟเวอร์	คำขอไม่เสร็จสมบูรณ์ เซิร์ฟเวอร์พบเงื่อนไขที่ไม่คาดคิด
501 ไม่ได้ดำเนินการ	คำขอไม่เสร็จสมบูรณ์ เซิร์ฟเวอร์ไม่รองรับฟังก์ชันที่จำเป็น
502 Bad Gateway	คำขอไม่เสร็จสมบูรณ์ เซิร์ฟเวอร์ได้รับการตอบสนองที่ไม่ถูกต้องจากเซิร์ฟเวอร์ต้นน้ำ
503 บริการไม่พร้อมใช้งาน	คำขอไม่เสร็จสมบูรณ์ เซิร์ฟเวอร์ทำงานเกินหรือหยุดทำงานชั่วคราว
504 เกตเวย์หมดเวลา	เกตเวย์หมดเวลาแล้ว
ไม่รองรับเวอร์ชัน HTTP 505	เซิร์ฟเวอร์ไม่รองรับเวอร์ชัน "โปรโตคอล http"

General-header: ฟิลด์ส่วนหัวเหล่านี้มีการบังคับใช้ทั่วไปสำหรับทั้งข้อความร้องขอและข้อความตอบกลับ
Client Request-header: ช่องส่วนหัวเหล่านี้ใช้สำหรับข้อความร้องขอเท่านั้น
Server Response-header: ช่องส่วนหัวเหล่านี้สามารถใช้ได้กับข้อความตอบกลับเท่านั้น
Entity-header: ฟิลด์ส่วนหัวเหล่านี้กำหนดข้อมูลเมตาเกี่ยวกับเอนทิตี - ร่างกายหรือหากไม่มีเนื้อหา

ส่วนหัวทั่วไป

การควบคุมแคช

ฟิลด์ Cache-Control general-header ใช้เพื่อระบุคำสั่งที่ระบบแคชทั้งหมดต้องปฏิบัติตาม ต่อไปนี้เป็นไวยากรณ์:

Cache-Control : cache-request-directive|cache-response-directive

ไคลเอ็นต์ HTTP หรือเซิร์ฟเวอร์สามารถใช้ไฟล์ Cache-controlส่วนหัวทั่วไปเพื่อระบุพารามิเตอร์สำหรับแคชหรือเพื่อขอเอกสารบางประเภทจากแคช คำสั่งการแคชถูกระบุไว้ในรายการที่คั่นด้วยเครื่องหมายจุลภาค ตัวอย่างเช่น:

Cache-control: no-cache

มีคำสั่งการร้องขอแคชที่สำคัญต่อไปนี้ซึ่งไคลเอนต์สามารถใช้ในคำขอ HTTP:

SN	คำสั่งและคำอธิบายคำขอแคช
1	no-cache แคชต้องไม่ใช้การตอบสนองเพื่อตอบสนองการร้องขอที่ตามมาหากไม่มีการตรวจสอบซ้ำกับเซิร์ฟเวอร์ต้นทาง
2	no-store แคชไม่ควรเก็บข้อมูลใด ๆ เกี่ยวกับคำขอของไคลเอ็นต์หรือการตอบสนองของเซิร์ฟเวอร์
3	max-age = seconds บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับการตอบกลับที่มีอายุไม่เกินเวลาที่ระบุเป็นวินาที
4	max-stale [ = seconds ] บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับการตอบกลับที่เกินเวลาหมดอายุ ถ้าให้เป็นวินาทีจะต้องไม่หมดอายุเกินเวลานั้น
5	min-fresh = seconds บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับคำตอบที่มีอายุการใช้งานใหม่ไม่น้อยกว่าอายุปัจจุบันบวกกับเวลาที่ระบุเป็นวินาที
6	no-transform อย่าแปลงเอนทิตี - ร่างกาย
7	only-if-cached อย่าดึงข้อมูลใหม่ แคชสามารถส่งเอกสารได้ก็ต่อเมื่ออยู่ในแคชและไม่ควรติดต่อเซิร์ฟเวอร์ต้นทางเพื่อดูว่ามีสำเนาที่ใหม่กว่าหรือไม่

มีคำสั่งการตอบกลับแคชที่สำคัญต่อไปนี้ซึ่งเซิร์ฟเวอร์สามารถใช้ในการตอบสนอง HTTP:

SN	คำสั่งและคำอธิบายคำขอแคช
1	public ระบุว่าการตอบกลับอาจถูกแคชโดยแคชใด ๆ
2	private ระบุว่าข้อความตอบกลับทั้งหมดหรือบางส่วนมีไว้สำหรับผู้ใช้คนเดียวและต้องไม่ถูกแคชโดยแคชที่แบ่งใช้
3	no-cache แคชต้องไม่ใช้การตอบสนองเพื่อตอบสนองการร้องขอที่ตามมาหากไม่มีการตรวจสอบซ้ำกับเซิร์ฟเวอร์ต้นทาง
4	no-store แคชไม่ควรเก็บข้อมูลใด ๆ เกี่ยวกับคำขอของไคลเอ็นต์หรือการตอบสนองของเซิร์ฟเวอร์
5	no-transform อย่าแปลงเอนทิตี - ร่างกาย
6	must-revalidate แคชต้องตรวจสอบสถานะของเอกสารเก่าก่อนที่จะใช้งานและไม่ควรใช้เอกสารที่หมดอายุ
7	proxy-revalidate คำสั่ง proxy-revalidate มีความหมายเหมือนกับคำสั่ง must- revalidate ยกเว้นว่าจะไม่ใช้กับแคชตัวแทนผู้ใช้ที่ไม่แบ่งใช้
8	max-age = seconds บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับการตอบกลับที่มีอายุไม่เกินเวลาที่ระบุเป็นวินาที
9	s-maxage = seconds อายุสูงสุดที่ระบุโดยคำสั่งนี้จะแทนที่อายุสูงสุดที่ระบุโดยคำสั่งอายุสูงสุดหรือส่วนหัวหมดอายุ คำสั่ง s-maxage จะถูกละเว้นโดยแคชส่วนตัวเสมอ

การเชื่อมต่อ

ฟิลด์ Connection general-header อนุญาตให้ผู้ส่งระบุอ็อพชันที่ต้องการสำหรับการเชื่อมต่อนั้น ๆ และต้องไม่สื่อสารโดยพร็อกซีผ่านการเชื่อมต่อเพิ่มเติม ต่อไปนี้เป็นไวยากรณ์ง่ายๆในการใช้ส่วนหัวการเชื่อมต่อ:

Connection : "Connection"

HTTP / 1.1 กำหนดตัวเลือกการเชื่อมต่อ "ปิด" สำหรับผู้ส่งเพื่อส่งสัญญาณว่าการเชื่อมต่อจะถูกปิดหลังจากเสร็จสิ้นการตอบสนอง ตัวอย่างเช่น:

Connection: Closed

โดยค่าเริ่มต้น HTTP 1.1 จะใช้การเชื่อมต่อแบบต่อเนื่องโดยที่การเชื่อมต่อจะไม่ปิดโดยอัตโนมัติหลังจากทำธุรกรรม ในทางกลับกัน HTTP 1.0 ไม่มีการเชื่อมต่อแบบถาวรตามค่าเริ่มต้น หากไคลเอนต์ 1.0 ต้องการใช้การเชื่อมต่อแบบถาวรจะใช้ไฟล์keep-alive พารามิเตอร์ดังนี้:

Connection: keep-alive

วันที่

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

รูปแบบแรกเป็นรูปแบบที่ต้องการมากที่สุด

Pragma

ฟิลด์ส่วนหัวทั่วไปของ Pragma ใช้เพื่อรวมคำสั่งเฉพาะการนำไปใช้งานที่อาจใช้กับผู้รับใด ๆ ตามห่วงโซ่การร้องขอ / การตอบกลับ ตัวอย่างเช่น:

Pragma: no-cache

คำสั่งเดียวที่กำหนดไว้ใน HTTP / 1.0 คือคำสั่งไม่มีแคชและคงไว้ใน HTTP 1.1 เพื่อความเข้ากันได้แบบย้อนหลัง จะไม่มีการกำหนดคำสั่ง Pragma ใหม่ในอนาคต

รถพ่วง

ค่าฟิลด์ทั่วไปของตัวอย่างระบุว่าชุดของฟิลด์ส่วนหัวที่ระบุนั้นมีอยู่ในส่วนท้ายของข้อความที่เข้ารหัสด้วยการเข้ารหัสการถ่ายโอนแบบเป็นกลุ่ม ต่อไปนี้เป็นไวยากรณ์ของช่องส่วนหัวของตัวอย่าง:

Trailer : field-name

ฟิลด์ส่วนหัวของข้อความที่แสดงในฟิลด์ส่วนหัวของตัวอย่างจะต้องไม่มีฟิลด์ส่วนหัวต่อไปนี้:

Transfer-Encoding
Content-Length
Trailer

โอน - เข้ารหัส

Transfer-Encodingสนามส่วนหัวทั่วไปแสดงให้เห็นว่าสิ่งที่ประเภทของการเปลี่ยนแปลงได้ถูกนำไปใช้กับเนื้อหาของข้อความในการสั่งซื้อเพื่อความปลอดภัยในการถ่ายโอนระหว่างผู้ส่งและผู้รับ สิ่งนี้ไม่เหมือนกับการเข้ารหัสเนื้อหาเนื่องจากการเข้ารหัสการถ่ายโอนเป็นคุณสมบัติของข้อความไม่ใช่ของเอนทิตี - เนื้อหา ต่อไปนี้เป็นไวยากรณ์ของฟิลด์ส่วนหัว Transfer-Encoding:

Transfer-Encoding: chunked

ค่า Transfer-coding ทั้งหมดไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่

อัพเกรด

อัพเกรดทั่วไปส่วนหัวช่วยให้ลูกค้าสามารถระบุสิ่งที่โปรโตคอลการสื่อสารเพิ่มเติมจะสนับสนุนและต้องการที่จะใช้ถ้าพบเซิร์ฟเวอร์มันเหมาะสมที่จะโปรโตคอลสวิทช์ ตัวอย่างเช่น:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

ฟิลด์ส่วนหัวของการอัพเกรดมีไว้เพื่อให้กลไกง่ายๆในการเปลี่ยนจาก HTTP / 1.1 ไปเป็นโปรโตคอลอื่นที่เข้ากันไม่ได้

ผ่าน

Viaทั่วไปส่วนหัวจะต้องนำมาใช้โดยเกตเวย์และผู้รับมอบฉันทะเพื่อระบุโปรโตคอลกลางและผู้รับ ตัวอย่างเช่นข้อความคำร้องขออาจถูกส่งจากเอเจนต์ผู้ใช้ HTTP / 1.0 ไปยังรหัสพร็อกซีภายในชื่อ "fred" ซึ่งใช้ HTTP / 1.1 เพื่อส่งต่อคำขอไปยังพร็อกซีสาธารณะที่ nowhere.com ซึ่งดำเนินการตามคำขอโดย ส่งต่อไปยังเซิร์ฟเวอร์ต้นทางที่ www.ics.uci.edu คำขอที่ได้รับโดย www.ics.uci.edu จะมีฟิลด์ส่วนหัว Via ต่อไปนี้:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

คำเตือน

คำเตือนหัวทั่วไปจะใช้ในการดำเนินการข้อมูลเพิ่มเติมเกี่ยวกับสถานะหรือการเปลี่ยนแปลงของข้อความซึ่งอาจจะไม่ได้สะท้อนให้เห็นในข้อความ คำตอบอาจมีส่วนหัวคำเตือนมากกว่าหนึ่งรายการ

Warning : warn-code SP warn-agent SP warn-text SP warn-date

ส่วนหัวคำขอของลูกค้า

ยอมรับ

ยอมรับข้อมูลการร้องขอส่วนหัวสามารถนำมาใช้เพื่อระบุประเภทสื่อบางอย่างที่เป็นที่ยอมรับสำหรับการตอบสนอง ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Accept: type/subtype [q=qvalue]

สื่อหลายประเภทสามารถแสดงรายการโดยคั่นด้วยเครื่องหมายจุลภาคและ qvalue ที่เป็นทางเลือกแสดงถึงระดับคุณภาพที่ยอมรับได้สำหรับประเภทการยอมรับในระดับ 0 ถึง 1 ต่อไปนี้เป็นตัวอย่าง:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

สิ่งนี้จะตีความได้ว่า text/html และ text/x-c เป็นประเภทสื่อที่ต้องการ แต่ถ้าไม่มีให้ส่งไฟล์ text/x-dvi เอนทิตีและหากไม่มีอยู่ให้ส่งไฟล์ text/plain นิติบุคคล.

ยอมรับ Charset

ช่องAccept-Charset request-header สามารถใช้เพื่อระบุว่าชุดอักขระใดบ้างที่ยอมรับได้สำหรับการตอบกลับ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Accept-Charset: character_set [q=qvalue]

ชุดอักขระหลายชุดสามารถแสดงรายการโดยคั่นด้วยเครื่องหมายจุลภาคและ qvalue ที่เป็นทางเลือกแสดงถึงระดับคุณภาพที่ยอมรับได้สำหรับชุดอักขระที่ไม่ต้องการในระดับ 0 ถึง 1 ต่อไปนี้เป็นตัวอย่าง:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

ค่าพิเศษ "*" หากมีอยู่ใน Accept-Charset ตรงกับทุกชุดอักขระและถ้าไม่มี Accept-Charset ส่วนหัวมีอยู่ค่าเริ่มต้นคือชุดอักขระใด ๆ ที่ยอมรับได้

ยอมรับการเข้ารหัส

ยอมรับการเข้ารหัสข้อมูลการร้องขอส่วนหัวคล้ายกับการยอมรับ แต่ จำกัด เนื้อหา codings ที่เป็นที่ยอมรับในการตอบสนอง ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Accept-Encoding: encoding types

ต่อไปนี้เป็นตัวอย่าง:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

ยอมรับภาษา

ยอมรับภาษาฟิลด์ร้องขอส่วนหัวคล้ายกับการยอมรับ แต่ จำกัด ชุดของภาษาธรรมชาติที่เป็นที่ต้องการเป็นตอบสนองต่อการร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Accept-Language: language [q=qvalue]

หลายภาษาสามารถแสดงรายการโดยคั่นด้วยเครื่องหมายจุลภาคและ qvalue ที่เป็นทางเลือกแสดงถึงระดับคุณภาพที่ยอมรับได้สำหรับภาษาที่ไม่ต้องการในระดับ 0 ถึง 1 ต่อไปนี้เป็นตัวอย่าง:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

การอนุญาต

การอนุมัติค่าของฟิลด์ request-header ประกอบด้วยข้อมูลประจำตัวที่มีข้อมูลการตรวจสอบของตัวแทนผู้ใช้สำหรับขอบเขตของทรัพยากรที่ถูกร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Authorization : credentials

ข้อกำหนด HTTP / 1.0 กำหนดโครงร่างการอนุญาตพื้นฐานโดยที่พารามิเตอร์การอนุญาตคือสตริงของ username:password เข้ารหัสในฐาน 64 ต่อไปนี้เป็นตัวอย่าง:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

ค่าที่ถอดรหัสเป็นคือ guest:guest123 ที่ไหน guest คือ ID ผู้ใช้และ guest123 คือรหัสผ่าน

คุกกี้

คุกกี้ค่าของฟิลด์คำขอส่วนหัวมีคู่ชื่อ / ค่าของข้อมูลที่เก็บไว้ URL นั้น ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Cookie: name=value

สามารถระบุคุกกี้หลายตัวโดยคั่นด้วยเครื่องหมายอัฒภาคดังนี้:

Cookie: name1=value1;name2=value2;name3=value3

คาดหวัง

คาดหวังว่าข้อมูลการร้องขอส่วนหัวถูกนำมาใช้เพื่อแสดงให้เห็นว่าพฤติกรรมเซิร์ฟเวอร์โดยเฉพาะอย่างยิ่งจะต้องโดยลูกค้า ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Expect : 100-continue | expectation-extension

หากเซิร์ฟเวอร์ได้รับคำขอที่มีฟิลด์ Expect ซึ่งมีส่วนขยายความคาดหวังที่ไม่รองรับเซิร์ฟเวอร์จะต้องตอบสนองด้วยสถานะ 417 (Expectation Failed)

จาก

จากข้อมูลการร้องขอส่วนหัวมีที่อยู่อีเมลทางอินเทอร์เน็ตสำหรับผู้ใช้มนุษย์เป็นผู้ควบคุมตัวแทนผู้ใช้ร้องขอ ต่อไปนี้เป็นตัวอย่างง่ายๆ:

From: [email protected]

ช่องส่วนหัวนี้อาจใช้เพื่อวัตถุประสงค์ในการบันทึกและเป็นช่องทางในการระบุแหล่งที่มาของคำขอที่ไม่ถูกต้องหรือไม่ต้องการ

โฮสต์

โฮสต์ฟิลด์ request-header ถูกใช้เพื่อระบุโฮสต์อินเทอร์เน็ตและหมายเลขพอร์ตของทรัพยากรการร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Host : "Host" ":" host [ ":" port ] ;

ก hostโดยไม่มีข้อมูลพอร์ตต่อท้ายแสดงถึงพอร์ตเริ่มต้นซึ่งเป็น 80 ตัวอย่างเช่นคำขอบนเซิร์ฟเวอร์ต้นทางสำหรับhttp://www.w3.org/pub/WWW/จะเป็น:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

ถ้าตรงกัน

จับคู่ถ้าฟิลด์ request-header จะใช้กับวิธีการที่จะทำให้มันมีเงื่อนไข ส่วนหัวนี้ขอให้เซิร์ฟเวอร์ดำเนินการตามวิธีการที่ร้องขอก็ต่อเมื่อค่าที่กำหนดในแท็กนี้ตรงกับแท็กเอนทิตีที่กำหนดซึ่งแสดงโดยETag. ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

If-Match : entity-tag

เครื่องหมายดอกจัน (*) ตรงกับเอนทิตีใด ๆ และธุรกรรมจะดำเนินต่อไปก็ต่อเมื่อมีเอนทิตีนั้นอยู่ ต่อไปนี้เป็นตัวอย่างที่เป็นไปได้:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

หากไม่มีแท็กเอนทิตีที่ตรงกันหรือระบุ "*" และไม่มีเอนทิตีปัจจุบันอยู่เซิร์ฟเวอร์จะต้องไม่ดำเนินการตามวิธีการที่ร้องขอและต้องส่งคืนการตอบสนอง 412 (Precondition Failed)

If-Modified-Since

If-Modified-ตั้งแต่ข้อมูลการร้องขอส่วนหัวใช้กับวิธีการที่จะทำให้มันมีเงื่อนไข หาก URL ที่ร้องขอไม่ได้รับการแก้ไขตั้งแต่เวลาที่ระบุไว้ในฟิลด์นี้เอนทิตีจะไม่ถูกส่งคืนจากเซิร์ฟเวอร์ แทนการตอบกลับ 304 (ไม่ได้แก้ไข) จะถูกส่งกลับโดยไม่มีข้อความ - เนื้อความใด ๆ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

If-Modified-Since : HTTP-date

ตัวอย่างของฟิลด์คือ:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

ถ้า - ไม่มี - ตรงกัน

หาก-ไม่มี-Matchฟิลด์ request-header จะใช้กับวิธีการที่จะทำให้มันมีเงื่อนไข ส่วนหัวนี้ขอให้เซิร์ฟเวอร์ดำเนินการตามวิธีการที่ร้องขอก็ต่อเมื่อค่าใดค่าหนึ่งในแท็กนี้ตรงกับแท็กเอนทิตีที่กำหนดซึ่งแสดงโดยETag. ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

If-None-Match : entity-tag

เครื่องหมายดอกจัน (*) ตรงกับเอนทิตีใด ๆ และธุรกรรมจะดำเนินต่อไปก็ต่อเมื่อไม่มีเอนทิตี ต่อไปนี้เป็นตัวอย่างที่เป็นไปได้:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

ถ้าช่วง

ถ้าช่วงข้อมูลการร้องขอส่วนหัวสามารถใช้กับได้รับเงื่อนไขที่จะขอเพียงส่วนหนึ่งของหน่วยงานที่จะหายไปถ้ามันยังไม่ได้รับการเปลี่ยนแปลงและหน่วยงานทั้งในกรณีที่มีการเปลี่ยนแปลง ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

If-Range : entity-tag | HTTP-date

สามารถใช้แท็กเอนทิตีหรือวันที่เพื่อระบุเอนทิตีบางส่วนที่ได้รับแล้ว ตัวอย่างเช่น:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

ในกรณีนี้หากเอกสารไม่ได้รับการแก้ไขตั้งแต่วันที่ที่กำหนดเซิร์ฟเวอร์จะส่งคืนช่วงไบต์ที่กำหนดโดยส่วนหัวของช่วงมิฉะนั้นจะส่งคืนเอกสารใหม่ทั้งหมด

ถ้าไม่แก้ไข - ตั้งแต่

หาก-ยังไม่แปร-ตั้งแต่ข้อมูลการร้องขอส่วนหัวใช้กับวิธีการที่จะทำให้มันมีเงื่อนไข ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

If-Unmodified-Since : HTTP-date

หากทรัพยากรที่ร้องขอไม่ได้รับการแก้ไขตั้งแต่เวลาที่ระบุในฟิลด์นี้เซิร์ฟเวอร์ควรดำเนินการตามที่ร้องขอราวกับว่าส่วนหัว If-Unmodified-Since ไม่มีอยู่ ตัวอย่างเช่น:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

หากโดยปกติคำขอจะส่งผลให้เกิดสิ่งอื่นที่ไม่ใช่สถานะ 2xx หรือ 412 ควรละเว้นส่วนหัวIf-Unmodified-Since

Max-Forwards

Max-ส่งต่อข้อมูลการร้องขอส่วนหัวมีกลไกที่มีการติดตามและตัวเลือกวิธีการที่จะ จำกัด จำนวนผู้รับมอบฉันทะหรือเกตเวย์ที่สามารถส่งคำขอไปยังเซิร์ฟเวอร์ขาเข้าต่อไป ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Max-Forwards : n

ค่า Max-Forwards คือจำนวนเต็มทศนิยมที่ระบุจำนวนครั้งที่เหลือของข้อความคำขอนี้อาจถูกส่งต่อ สิ่งนี้มีประโยชน์สำหรับการดีบักด้วยเมธอด TRACE หลีกเลี่ยงการวนซ้ำที่ไม่มีที่สิ้นสุด ตัวอย่างเช่น:

Max-Forwards : 5

ช่องส่วนหัว Max-Forwards อาจถูกละเว้นสำหรับวิธีการอื่น ๆ ทั้งหมดที่กำหนดไว้ในข้อกำหนด HTTP

Proxy-Authorization

Proxy-Authorizationฟิลด์ request-header ช่วยให้ลูกค้าสามารถระบุตัวเอง (หรือผู้ใช้) พร็อกซีซึ่งจะต้องมีการตรวจสอบสิทธิ์ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Proxy-Authorization : credentials

ค่าฟิลด์ Proxy-Authorization ประกอบด้วยหนังสือรับรองที่มีข้อมูลการพิสูจน์ตัวตนของตัวแทนผู้ใช้สำหรับพร็อกซีและ / หรือขอบเขตของทรัพยากรที่ร้องขอ

พิสัย

ช่วง request-header ฟิลด์ระบุช่วงบางส่วน (s) ของเนื้อหาที่ได้รับการร้องขอจากเอกสาร ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

ค่าไบต์แรกในช่วงข้อมูลจำเพาะของไบต์จะให้ค่าไบต์ออฟเซ็ตของไบต์แรกในช่วง ค่า last-byte-pos ให้ค่า byte-offset ของไบต์สุดท้ายในช่วง นั่นคือตำแหน่งไบต์ที่ระบุจะรวมอยู่ด้วย คุณสามารถระบุหน่วยไบต์เป็นไบต์ออฟเซ็ตไบต์เริ่มต้นที่ศูนย์ ต่อไปนี้เป็นตัวอย่างง่ายๆ:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

สามารถแสดงรายการได้หลายช่วงโดยคั่นด้วยเครื่องหมายจุลภาค หากตัวเลขหลักแรกในช่วงไบต์ที่คั่นด้วยเครื่องหมายจุลภาคหายไปช่วงจะถือว่านับจากตอนท้ายของเอกสาร หากตัวเลขหลักที่สองหายไปช่วงจะเป็นไบต์ n ไปยังส่วนท้ายของเอกสาร

ผู้อ้างอิง

Refererฟิลด์ request-header ช่วยให้ลูกค้าสามารถระบุที่อยู่ (URI) ของทรัพยากรจาก URL ที่ได้รับการร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Referer : absoluteURI | relativeURI

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Referer: http://www.tutorialspoint.org/http/index.htm

ถ้าค่าของฟิลด์เป็นญาติ URI ก็ควรจะตีความเทียบกับการขอ URI

TE

TEฟิลด์คำขอหัวระบุว่าการขยายการถ่ายโอนการเข้ารหัสมันก็เต็มใจที่จะยอมรับในการตอบสนองหรือไม่และมันก็เต็มใจที่จะยอมรับเขตพ่วงใน chunked โอนเข้ารหัส ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

TE   : t-codings

การมีคีย์เวิร์ด "trailer" บ่งชี้ว่าลูกค้ายินดีที่จะยอมรับฟิลด์เทรลเลอร์ในรูปแบบการโอนโค้ดแบบเป็นกลุ่มและมีการระบุด้วยวิธีใดวิธีหนึ่ง:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

หาก TE ฟิลด์ที่มีมูลค่าเป็นที่ว่างเปล่าหรือถ้าไม่มีข้อมูล TE เป็นปัจจุบันเท่านั้นโอน-เข้ารหัสchunked ยอมรับข้อความที่ไม่มีการเข้ารหัสการถ่ายโอนเสมอ

ตัวแทนผู้ใช้

User-Agentฟิลด์ request-header มีข้อมูลเกี่ยวกับตัวแทนของผู้ใช้ที่มีต้นกำเนิดการร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

User-Agent : product | comment

ตัวอย่าง:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

ส่วนหัวการตอบกลับของเซิร์ฟเวอร์

ช่วงการยอมรับ

ฟิลด์ส่วนหัวการตอบกลับช่วงการยอมรับอนุญาตให้เซิร์ฟเวอร์ระบุการยอมรับการร้องขอช่วงสำหรับทรัพยากร ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Accept-Ranges  : range-unit | none

ตัวอย่างเช่นเซิร์ฟเวอร์ที่ยอมรับการร้องขอช่วงไบต์อาจส่ง

Accept-Ranges: bytes

เซิร์ฟเวอร์ที่ไม่ยอมรับการร้องขอช่วงใด ๆ สำหรับทรัพยากรอาจส่ง:

Accept-Ranges: none

สิ่งนี้จะแนะนำลูกค้าว่าอย่าพยายามร้องขอช่วง

อายุ

อายุฟิลด์การตอบสนองหัวบ่งบอกถึงการประมาณการของผู้ส่งของจำนวนเงินของเวลาตั้งแต่การตอบสนอง (หรือ revalidation ของมัน) ถูกสร้างขึ้นที่เซิร์ฟเวอร์ต้นทาง ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Age : delta-seconds

ค่าอายุเป็นจำนวนเต็มทศนิยมที่ไม่เป็นลบซึ่งแสดงเวลาเป็นวินาที ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Age: 1030

เซิร์ฟเวอร์ HTTP / 1.1 ที่มีแคชต้องมีฟิลด์ส่วนหัวอายุในทุกการตอบสนองที่สร้างจากแคชของตัวเอง

ETag

ETagฟิลด์ตอบสนองส่วนหัวให้มูลค่าปัจจุบันของแท็กนิติบุคคลสำหรับตัวแปรที่ร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

ETag :  entity-tag

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

สถานที่

สถานที่ตั้งเขตการตอบสนองส่วนหัวจะใช้ในการเปลี่ยนเส้นทางผู้รับไปยังสถานที่อื่นที่ไม่ใช่การขอ URI สำหรับเสร็จ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Location : absoluteURI

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Location: http://www.tutorialspoint.org/http/index.htm

ฟิลด์ Content-Location header แตกต่างจาก Location ตรงที่ Content-Location ระบุตำแหน่งดั้งเดิมของเอนทิตีที่อยู่ในคำร้องขอ

Proxy-Authenticate

พร็อกซี Authenticateฟิลด์ตอบสนองส่วนหัวจะต้องรวมเป็นส่วนหนึ่งของ (Proxy รับรองความถูกต้องจำเป็น) การตอบสนองต่อ 407 ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Proxy-Authenticate  : challenge

ลองอีกครั้งหลังจาก

ลองอีกครั้งหลังจากข้อมูลการตอบสนองส่วนหัวสามารถนำมาใช้กับ 503 (บริการไม่พร้อมใช้งาน) การตอบสนองเพื่อแสดงให้เห็นว่าระยะเวลาที่ให้บริการที่คาดว่าจะไม่สามารถใช้ได้กับลูกค้าร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Retry-After : HTTP-date | delta-seconds

ต่อไปนี้เป็นสองตัวอย่างง่ายๆ:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

ในตัวอย่างหลังความล่าช้าคือ 2 นาที

เซิร์ฟเวอร์

เซิร์ฟเวอร์ข้อมูลการตอบสนองส่วนหัวมีข้อมูลเกี่ยวกับซอฟต์แวร์ที่ใช้โดยเซิร์ฟเวอร์ต้นทางที่จะจัดการกับคำขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Server : product | comment

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Server: Apache/2.2.14 (Win32)

หากการตอบกลับถูกส่งต่อผ่านพร็อกซีแอ็พพลิเคชันพร็อกซีต้องไม่แก้ไขส่วนหัวการตอบกลับของเซิร์ฟเวอร์

ชุดคุกกี้

คุกกี้ชุดข้อมูลการตอบสนองส่วนหัวมีคู่ชื่อ / ค่าของข้อมูลที่จะเก็บสำหรับ URL นี้ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Set-Cookie: NAME=VALUE; OPTIONS

ส่วนหัวการตอบกลับ Set-Cookie ประกอบด้วยโทเค็น Set-Cookie: ตามด้วยรายการคุกกี้หนึ่งรายการหรือมากกว่าที่คั่นด้วยเครื่องหมายจุลภาค ค่าที่เป็นไปได้ที่คุณระบุเป็นตัวเลือกได้มีดังนี้

SN	ตัวเลือกและคำอธิบาย
1	Comment=comment ตัวเลือกนี้สามารถใช้เพื่อระบุความคิดเห็นใด ๆ ที่เกี่ยวข้องกับคุกกี้
2	Domain=domain แอตทริบิวต์โดเมนระบุโดเมนที่คุกกี้ถูกต้อง
3	Expires=Date-time วันที่คุกกี้จะหมดอายุ หากว่างเปล่าคุกกี้จะหมดอายุเมื่อผู้เยี่ยมชมออกจากเบราว์เซอร์
4	Path=path แอตทริบิวต์ Path ระบุส่วนย่อยของ URL ที่ใช้คุกกี้นี้
5	Secure คำสั่งนี้จะสั่งให้ตัวแทนผู้ใช้ส่งคืนคุกกี้ภายใต้การเชื่อมต่อที่ปลอดภัยเท่านั้น

ต่อไปนี้เป็นตัวอย่างของส่วนหัวคุกกี้แบบง่ายที่เซิร์ฟเวอร์สร้างขึ้น:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

แตกต่างกันไป

วารีตอบสนองส่วนหัวระบุเขตข้อมูลที่กิจการมีหลายแหล่งและดังนั้นจึงอาจแตกต่างกันไปตามรายการที่ระบุหัวข้อการร้องขอ (s) ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Vary : field-name

คุณสามารถระบุส่วนหัวหลายรายการโดยคั่นด้วยเครื่องหมายจุลภาคและค่าของเครื่องหมายดอกจัน "*" ส่งสัญญาณว่าพารามิเตอร์ที่ไม่ระบุไม่ จำกัด เฉพาะส่วนหัวของคำขอ ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Vary: Accept-Language, Accept-Encoding

ชื่อฟิลด์ต่อไปนี้ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่

WWW- รับรองความถูกต้อง

WWW-Authenticateฟิลด์ตอบสนองส่วนหัวต้องรวมอยู่ใน 401 (ไม่ได้รับอนุญาต) ข้อความการตอบสนอง ค่าฟิลด์ประกอบด้วยความท้าทายอย่างน้อยหนึ่งรายการที่ระบุรูปแบบการพิสูจน์ตัวตนและพารามิเตอร์ที่ใช้กับ Request-URI ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

WWW-Authenticate : challenge

WWW- ตรวจสอบความถูกต้องของค่าฟิลด์เนื่องจากอาจมีมากกว่าหนึ่งความท้าทายหรือหากมีการระบุฟิลด์ส่วนหัว WWW-Authenticate มากกว่าหนึ่งฟิลด์เนื้อหาของความท้าทายสามารถมีรายการพารามิเตอร์การพิสูจน์ตัวตนที่คั่นด้วยเครื่องหมายจุลภาค ต่อไปนี้เป็นตัวอย่างง่ายๆ:

WWW-Authenticate: BASIC realm="Admin"

ส่วนหัวของเอนทิตี

อนุญาต

อนุญาตให้แสดงรายการข้อมูลนิติบุคคลหัวชุดของวิธีการที่สนับสนุนโดยทรัพยากรที่ระบุโดยขอ URI ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Allow : Method

คุณสามารถระบุหลายวิธีโดยคั่นด้วยเครื่องหมายจุลภาค ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Allow: GET, HEAD, PUT

ฟิลด์นี้ไม่สามารถป้องกันไคลเอนต์จากการลองวิธีอื่น

การเข้ารหัสเนื้อหา

เนื้อหาการเข้ารหัสข้อมูลนิติบุคคลส่วนหัวจะถูกใช้เป็นตัวปรับแต่งกับสื่อประเภท ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-Encoding : content-coding

การเข้ารหัสเนื้อหาเป็นลักษณะเฉพาะของเอนทิตีที่ระบุโดย Request-URI ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Content-Encoding: gzip

หากการเข้ารหัสเนื้อหาของเอนทิตีในข้อความร้องขอไม่เป็นที่ยอมรับสำหรับเซิร์ฟเวอร์ต้นทางเซิร์ฟเวอร์ควรตอบสนองด้วยรหัสสถานะเป็น 415 (ประเภทสื่อที่ไม่รองรับ)

เนื้อหา - ภาษา

เนื้อหาภาษาฟิลด์นิติบุคคลหัวอธิบายภาษาธรรมชาติ (s) ของผู้ชมที่ตั้งใจไว้สำหรับนิติบุคคลที่แนบมา ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-Language : language-tag

อาจมีหลายภาษาสำหรับเนื้อหาที่มีไว้สำหรับผู้ชมหลายคน ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Content-Language: mi, en

วัตถุประสงค์หลักของ Content-Language คือการอนุญาตให้ผู้ใช้ระบุและแยกความแตกต่างของเอนทิตีตามภาษาที่ผู้ใช้ต้องการ

ความยาวของเนื้อหา

ความยาวเนื้อหาข้อมูลนิติบุคคลหัวบ่งชี้ขนาดของกิจการร่างกายในจำนวนทศนิยมของ octets ส่งไปยังผู้รับหรือในกรณีของวิธีศีรษะขนาดของกิจการร่างกายที่จะได้รับการส่งได้ คำขอเป็น GET ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-Length : DIGITS

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Content-Length: 3495

ความยาวของเนื้อหาใด ๆ ที่มากกว่าหรือเท่ากับศูนย์เป็นค่าที่ถูกต้อง

เนื้อหา - สถานที่

ตั้งเนื้อหาที่สนามนิติบุคคลส่วนหัวอาจจะใช้ในการจัดหาสถานที่ตั้งของทรัพยากรสำหรับกิจการที่อยู่ในข้อความเมื่อหน่วยงานที่สามารถเข้าถึงได้จากสถานที่ที่แยกต่างหากจาก URI ทรัพยากรที่ร้องขอ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-Location:  absoluteURI | relativeURI

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Content-Location: http://www.tutorialspoint.org/http/index.htm

ค่าของ Content-Location ยังกำหนด URI พื้นฐานสำหรับเอนทิตี

เนื้อหา -MD5

เนื้อหา MD5ข้อมูลนิติบุคคลส่วนหัวอาจจะใช้เพื่อจัดหา MD5 ย่อยของกิจการสำหรับการตรวจสอบความสมบูรณ์ของข้อความบนใบเสร็จรับเงิน ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

ต่อไปนี้เป็นตัวอย่างง่ายๆ:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5 ไดเจสต์คำนวณตามเนื้อหาของเอนทิตี - บอดี้รวมถึงการเข้ารหัสเนื้อหาใด ๆ ที่ถูกนำไปใช้ แต่ไม่รวมถึงการเข้ารหัสการถ่ายโอนใด ๆ ที่ใช้กับเนื้อหาของข้อความ

ช่วงเนื้อหา

เนื้อหาช่วงข้อมูลนิติบุคคลส่วนหัวถูกส่งไปพร้อมกับนิติบุคคลที่ร่างกายบางส่วนเพื่อระบุตำแหน่งในกิจการที่เต็มร่างกายร่างกายบางส่วนควรจะใช้ ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

ตัวอย่างของค่าข้อมูลจำเพาะของช่วงเนื้อหาโดยสมมติว่าเอนทิตีมีทั้งหมด 1234 ไบต์:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

เมื่อข้อความ HTTP มีเนื้อหาของช่วงเดียวเนื้อหานี้จะถูกส่งด้วยส่วนหัวของช่วงเนื้อหาและส่วนหัวความยาวของเนื้อหาจะแสดงจำนวนไบต์ที่ถ่ายโอนจริง ตัวอย่างเช่น,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

ชนิดของเนื้อหา

ชนิดเนื้อหาข้อมูลนิติบุคคลหัวบ่งบอกถึงประเภทของสื่อของนิติบุคคลร่างกายส่งไปยังผู้รับหรือในกรณีของวิธีศีรษะสื่อพิมพ์ที่จะได้รับการส่งได้รับการร้องขอการ GET ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Content-Type : media-type

ต่อไปนี้เป็นตัวอย่าง:

Content-Type: text/html; charset=ISO-8859-4

หมดอายุ

หมดอายุฟิลด์นิติบุคคลส่วนหัวให้วันที่ / เวลาหลังจากที่การตอบสนองถือว่าเก่า ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Expires : HTTP-date

ต่อไปนี้เป็นตัวอย่าง:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

ล่าสุด - แก้ไข

Last-Modifiedข้อมูลนิติบุคคลหัวบ่งบอกวันที่และเวลาที่เซิร์ฟเวอร์ต้นทางเชื่อตัวแปรแก้ไขล่าสุด ต่อไปนี้เป็นไวยากรณ์ทั่วไป:

Last-Modified: HTTP-date

ต่อไปนี้เป็นตัวอย่าง:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

โดยทั่วไปแล้ว HTTP จะใช้สำหรับระบบข้อมูลแบบกระจายซึ่งสามารถปรับปรุงประสิทธิภาพได้โดยใช้แคชตอบกลับ โปรโตคอล HTTP / 1.1 ประกอบด้วยองค์ประกอบจำนวนหนึ่งที่มีไว้เพื่อให้การแคชทำงานได้

เป้าหมายของการแคชใน HTTP / 1.1 คือการขจัดความจำเป็นในการส่งคำขอในหลาย ๆ กรณีและเพื่อขจัดความจำเป็นในการส่งคำตอบแบบเต็มในกรณีอื่น ๆ อีกมากมาย

กลไกแคชพื้นฐานใน HTTP / 1.1 เป็นคำสั่งโดยปริยายสำหรับแคชที่เซิร์ฟเวอร์ระบุเวลาหมดอายุและตัวตรวจสอบความถูกต้อง เราใช้ไฟล์Cache-Control ส่วนหัวสำหรับวัตถุประสงค์นี้

Cache-Controlส่วนหัวช่วยให้ไคลเอนต์หรือเซิร์ฟเวอร์ส่งคำสั่งที่หลากหลายในคำขอหรือการตอบกลับ โดยทั่วไปคำสั่งเหล่านี้จะแทนที่อัลกอริทึมการแคชเริ่มต้น คำสั่งการแคชถูกระบุไว้ในรายการที่คั่นด้วยเครื่องหมายจุลภาค ตัวอย่างเช่น:

Cache-control: no-cache

มีคำสั่งการร้องขอแคชที่สำคัญต่อไปนี้ซึ่งไคลเอนต์สามารถใช้ในคำขอ HTTP:

SN	คำสั่งและคำอธิบายคำขอแคช
1	no-cache แคชต้องไม่ใช้การตอบสนองเพื่อตอบสนองการร้องขอที่ตามมาหากไม่มีการตรวจสอบซ้ำกับเซิร์ฟเวอร์ต้นทาง
2	no-store แคชไม่ควรเก็บข้อมูลใด ๆ เกี่ยวกับคำขอของไคลเอ็นต์หรือการตอบสนองของเซิร์ฟเวอร์
3	max-age = seconds บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับการตอบกลับที่มีอายุไม่เกินเวลาที่ระบุเป็นวินาที
4	max-stale [ = seconds ] บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับการตอบกลับที่เกินเวลาหมดอายุ ถ้าให้เป็นวินาทีจะต้องไม่หมดอายุเกินเวลานั้น
5	min-fresh = seconds บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับคำตอบที่มีอายุการใช้งานใหม่ไม่น้อยกว่าอายุปัจจุบันบวกกับเวลาที่ระบุเป็นวินาที
6	no-transform อย่าแปลงเอนทิตี - ร่างกาย
7	only-if-cached อย่าดึงข้อมูลใหม่ แคชสามารถส่งเอกสารได้ก็ต่อเมื่ออยู่ในแคชและไม่ควรติดต่อเซิร์ฟเวอร์ต้นทางเพื่อดูว่ามีสำเนาที่ใหม่กว่าหรือไม่

SN	คำสั่งและคำอธิบายการตอบสนองแคช
1	public ระบุว่าการตอบกลับอาจถูกแคชโดยแคชใด ๆ
2	private ระบุว่าข้อความตอบกลับทั้งหมดหรือบางส่วนมีไว้สำหรับผู้ใช้คนเดียวและต้องไม่ถูกแคชโดยแคชที่แบ่งใช้
3	no-cache แคชต้องไม่ใช้การตอบสนองเพื่อตอบสนองการร้องขอที่ตามมาหากไม่มีการตรวจสอบซ้ำกับเซิร์ฟเวอร์ต้นทาง
4	no-store แคชไม่ควรเก็บข้อมูลใด ๆ เกี่ยวกับคำขอของไคลเอ็นต์หรือการตอบสนองของเซิร์ฟเวอร์
5	no-transform อย่าแปลงเอนทิตี - ร่างกาย
6	must-revalidate แคชต้องตรวจสอบสถานะของเอกสารเก่าก่อนที่จะใช้งานและไม่ควรใช้เอกสารที่หมดอายุ
7	proxy-revalidate คำสั่ง proxy-revalidate มีความหมายเหมือนกับคำสั่ง must- revalidate ยกเว้นว่าจะไม่ใช้กับแคชตัวแทนผู้ใช้ที่ไม่แบ่งใช้
8	max-age = seconds บ่งชี้ว่าไคลเอนต์ยินดีที่จะยอมรับการตอบกลับที่มีอายุไม่เกินเวลาที่ระบุเป็นวินาที
9	s-maxage = seconds อายุสูงสุดที่ระบุโดยคำสั่งนี้จะแทนที่อายุสูงสุดที่ระบุโดยคำสั่งอายุสูงสุดหรือส่วนหัวหมดอายุ คำสั่ง s-maxage จะถูกละเว้นโดยแคชส่วนตัวเสมอ

HTTP URL ที่สามารถส่งผ่านทางอินเทอร์เน็ตโดยใช้ ASCII ตัวตั้งซึ่งมักจะมีตัวละครนอกชุดแอสกี ดังนั้นอักขระที่ไม่ปลอดภัยเหล่านี้จะต้องถูกแทนที่ด้วย% ตามด้วยเลขฐานสิบหกสองหลัก

ตารางต่อไปนี้แสดงสัญลักษณ์ ASCII ของอักขระและสัญลักษณ์ที่เท่ากันและสุดท้ายแทนที่ซึ่งสามารถใช้ใน URL ก่อนที่จะส่งไปยังเซิร์ฟเวอร์:

ASCII	สัญลักษณ์	เปลี่ยน
<32		เข้ารหัสด้วย% xx โดยที่ xx เป็นตัวแทนฐานสิบหกของอักขระ
32	พื้นที่	+ หรือ% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	$	% 24
37	%	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	<	% 3C
61	=	% 3D
62	>	% 3E
63	เหรอ?	% 3F
64	@	% 40
65	ก	ก
66	ข	ข
67	ค	ค
68	ง	ง
69	จ	จ
70	ฉ	ฉ
71	ช	ช
72	ซ	ซ
73	ผม	ผม
74	เจ	เจ
75	เค	เค
76	ล	ล
77	ม	ม
78	น	น
79	โอ	โอ
80	ป	ป
81	ถาม	ถาม
82	ร	ร
83	ส	ส
84	ที	ที
85	ยู	ยู
86	วี	วี
87	ว	ว
88	X	X
89	ย	ย
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	`	60%
97	ก	ก
98	ข	ข
99	ค	ค
100	ง	ง
101	จ	จ
102	ฉ	ฉ
103	ก	ก
104	ซ	ซ
105	ผม	ผม
106	ญ	ญ
107	k	k
108	ล	ล
109	ม	ม
110	n	n
111	o	o
112	น	น
113	q	q
114	ร	ร
115	เอส	เอส
116	t	t
117	ยู	ยู
118	v	v
119	ว	ว
120	x	x
121	ย	ย
122	z	z
123	{	% 7B
124	\|	%7C
125	}	%7D
126	~	%7E
127		%7F
> 127		Encode with %xx where xx is the hexadecimal representation of the character

HTTP is used for a communication over the internet, so application developers, information providers, and users should be aware of the security limitations in HTTP/1.1. This discussion does not include definitive solutions to the problems mentioned here but it does make some suggestions for reducing security risks.

Personal Information leakage

HTTP clients are often privy to large amounts of personal information such as the user's name, location, mail address, passwords, encryption keys, etc. So you should be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources.

All the confidential information should be stored at server side in encrypted form.
Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.
Proxies which serve as a portal through a network firewall should take special precautions regarding the transfer of header information that identifies the hosts behind the firewall.
The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it should not be transmitted without the user being able to disable, enable, and modify the contents of the field.
Clients should not include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
Authors of services which use the HTTP protocol should not use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI

File and path names based attack

The document should be restricted to the documents returned by HTTP requests to be only those that were intended by the server administrators.

For example, UNIX, Microsoft Windows, and other operating systems use .. as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server.

DNS Spoofing

Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. So clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.

If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they must observe the TTL information reported by DNS. If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes.

Location Headers and Spoofing

If a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.

Authentication Credentials

Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials which is a big security risk.

There are a number of work- arounds to parts of this problem, and so its is recommended to make the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem.

Proxies and Caching

HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers.

Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information.

Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Therefore, cache contents should be protected as sensitive information.

Example 1

HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com

Client request

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Server response

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Example 2

HTTP request to fetch t.html page which does not exist on the web server running on tutorialspoint.com

Client request

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Server response

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Example 3

HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com, but request goes with wrong HTTP version:

Client request

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Server response

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Example 4

HTTP request to post form data to process.cgi CGI page on a web server running on tutorialspoint.com. Server returns passed name after setting them as cookies:

Client request

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

Server response

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>