เกณฑ์วิธีขนส่งข้อความหลายมิติ หรือ เอชทีทีพี (อังกฤษ: HyperText Transfer Protocol: HTTP) คือโพรโทคอลในระดับชั้นโปรแกรมประยุกต์เพื่อการแจกจ่ายและการทำงานร่วมกันกับสารสนเทศของสื่อผสม ใช้สำหรับการรับทรัพยากรที่เชื่อมโยงกับภายนอก ซึ่งนำไปสู่การจัดตั้งเวิลด์ไวด์เว็บ
มาตรฐานสากล |
|
---|---|
ผู้พัฒนา | เริ่มต้นโดย CERN; IETF, W3C |
ริเริ่ม | 1991 |
เว็บไซต์ | https://httpwg.org/specs/ |
การพัฒนาเอชทีทีพีเป็นการทำงานร่วมกันของเวิลด์ไวด์เว็บคอนซอร์เทียม (W3C) และคณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต (IETF) ซึ่งมีผลงานเด่นในการเผยแพร่เอกสารขอความเห็น (RFC) หลายชุด เอกสารที่สำคัญที่สุดคือ RFC 2616 (เดือนมิถุนายน พ.ศ. 2542) ได้กำหนด HTTP/1.1 ซึ่งเป็นรุ่นที่ใช้กันอย่างกว้างขวางในปัจจุบัน
เอชทีทีพีเป็นมาตรฐานในการร้องขอและการตอบรับระหว่างเครื่องลูกข่ายกับเครื่องแม่ข่าย ซึ่งเครื่องลูกข่ายคือผู้ใช้ปลายทาง (end-user) และเครื่องแม่ข่ายคือเว็บไซต์ เครื่องลูกข่ายจะสร้างการร้องขอเอชทีทีพีผ่านทางเว็บเบราว์เซอร์ เว็บครอว์เลอร์ หรือเครื่องมืออื่น ๆ ที่จัดว่าเป็น (user agent) ส่วนเครื่องแม่ข่ายที่ตอบรับ ซึ่งเก็บบันทึกหรือสร้าง ทรัพยากร (resource) อย่างเช่นไฟล์เอชทีเอ็มแอลหรือรูปภาพ จะเรียกว่า เครื่องให้บริการต้นทาง (origin server) ในระหว่างตัวแทนผู้ใช้กับเครื่องให้บริการต้นทางอาจมีสื่อกลางหลายชนิด อาทิพร็อกซี เกตเวย์ และ เอชทีทีพีไม่ได้จำกัดว่าจะต้องใช้ (TCP/IP) เท่านั้น แม้ว่าจะเป็นการใช้งานที่นิยมมากที่สุดบนอินเทอร์เน็ตก็ตาม โดยแท้จริงแล้วเอชทีทีพีสามารถ "นำไปใช้ได้บนโพรโทคอลอินเทอร์เน็ตอื่น ๆ หรือบนเครือข่ายอื่นก็ได้" เอชทีทีพีคาดหวังเพียงแค่การสื่อสารที่เชื่อถือได้ นั่นคือโพรโทคอลที่มีการรับรองเช่นนั้นก็สามารถใช้งานได้
ปกติเครื่องลูกข่ายเอชทีทีพีจะเป็นผู้เริ่มสร้างการร้องขอก่อน โดยเปิดการเชื่อมต่อด้วยเกณฑ์วิธีควบคุมการขนส่งข้อมูล (TCP) ไปยังเฉพาะของเครื่องแม่ข่าย (พอร์ต 80 เป็นค่าปริยาย) เครื่องแม่ข่ายเอชทีทีพีที่เปิดรอรับอยู่ที่พอร์ตนั้น จะเปิดรอให้เครื่องลูกข่ายส่งข้อความร้องขอเข้ามา เมื่อได้รับการร้องขอแล้ว เครื่องแม่ข่ายจะตอบรับด้วยข้อความสถานะอันหนึ่ง ตัวอย่างเช่น "HTTP/1.1 200 OK
" ตามด้วยเนื้อหาของมันเองส่งไปด้วย เนื้อหานั้นอาจเป็นแฟ้มข้อมูลที่ร้องขอ ข้อความแสดงข้อผิดพลาด หรือข้อมูลอย่างอื่นเป็นต้น
ทรัพยากรที่ถูกเข้าถึงด้วยเอชทีทีพีจะถูกระบุโดยใช้ (URI) (หรือเจาะจงลงไปก็คือ ตัวชี้แหล่งในอินเทอร์เน็ต (URL)) โดยใช้ http: หรือ https: เป็น (URI scheme)
ข้อความร้องขอ
ข้อความร้องขอประกอบด้วยสิ่งต่อไปนี้
- บรรทัดแรก ขึ้นต้นเป็นคำสั่งร้องขอ และเส้นทางไดเรกทอรีของแฟ้มที่ร้องขอ ตามด้วยรุ่นของ HTTP ตัวอย่างเช่น GET /images/logo.gif HTTP/1.1
- บรรทัดต่อๆ ไปที่ไม่ใช่บรรทัดว่าง เรียกว่าเป็น ส่วนหัว (header) เป็นเมทาเดตาต่าง ๆ ประกอบการร้องขอ ตัวอย่างเช่น Accept-Language: en
- บรรทัดว่าง เพื่อแบ่งแยกระหว่างส่วนหัวกับเนื้อหา
- บรรทัดต่อๆ ไป เป็นเนื้อหาข้อมูล ซึ่งบางคำสั่งอาจไม่จำเป็นต้องใช้ส่วนนี้
แต่ละบรรทัดจะต้องลงท้ายด้วย CRLF (อักขระตามด้วยอักขระ เหมือนการกดปุ่ม Enter ในวินโดวส์) บรรทัดที่ว่างจะมีเพียงแค่ CRLF เท่านั้นโดยไม่มีอักขระช่องว่างอยู่เลย สำหรับรุ่น HTTP/1.1 ส่วนหัว Host: จำเป็นต้องมีเสมอ แต่ส่วนหัวอื่น ๆ ไม่จำเป็นต้องมีก็ได้
บรรทัดคำสั่งที่มีเพียงเส้นทางไดเรกทอรี (ไม่มีชื่อแฟ้ม) ก็เป็นที่ยอมรับโดยเครื่องแม่ข่าย เพื่อรักษาความเข้ากันได้กับโปรแกรมตัวแทนรุ่นเก่าก่อนที่จะมีข้อกำหนดของ HTTP/1.0 ใน RFC 1945 ส่วน HTTP/1.1 ได้กำหนดไว้ใน RFC 2068
คำสั่งร้องขอ
เอชทีทีพีได้กำหนดคำสั่งร้องขอไว้แปดคำสั่ง (หรือเรียกว่าวิธีการร้องขอ บางครั้งอาจเรียกว่าเป็น "กริยา") แสดงการกระทำที่ต้องการ เพื่อที่จะดำเนินการกับทรัพยากรที่ถูกระบุ สิ่งที่ทรัพยากรนั้นนำเสนอ ไม่ว่าเป็นข้อมูลที่มีอยู่ก่อนหรือสร้างขึ้นมาแบบพลวัตก็ตาม จะขึ้นอยู่กับการนำไปใช้ของเครื่องแม่ข่าย ซึ่งบ่อยครั้งทรัพยากรมักจะสอดคล้องกับไฟล์ หรือผลลัพธ์ส่งออกจากโปรแกรมข้างเคียงในเครื่องแม่ข่ายนั้น เครื่องให้บริการเอชทีทีพีจะต้องสามารถใช้คำสั่ง GET และ HEAD ได้เป็นอย่างน้อย
- HEAD
- ร้องขอการตอบรับจากทรัพยากรที่ระบุ คล้ายกับ GET แต่จะไม่มีส่วนเนื้อหาที่ร้องขอกลับมา คำสั่งนี้ใช้ประโยชน์ในการตรวจสอบข้อมูลส่วนหัวของการตอบรับ โดยไม่จำเป็นต้องส่งเนื้อหาเต็มมาทั้งหมด
- GET
- ร้องขอการนำเสนอจากทรัพยากรที่ระบุ คำสั่งนี้ไม่ควรใช้กับการดำเนินการที่อาจทำให้เกิดผลข้างเคียง เช่นการจัดการในเว็บแอปพลิเคชัน เหตุผลหนึ่งคือคำสั่ง GET มักจะถูกใช้อย่างไม่มีกฎเกณฑ์โดยอินเทอร์เน็ตบอตและเว็บครอว์เลอร์ ซึ่งไม่ควรพิจารณาให้การร้องขอของบอตและครอว์เลอร์ส่งผลกระทบต่อทรัพยากรในเว็บ (ดูเพิ่มที่หัวข้อ คำสั่งที่ปลอดภัย)
- POST
- ส่งข้อมูลไปยังทรัพยากรที่ระบุเพื่อให้นำไปประมวลผล โดยเฉพาะข้อมูลที่ส่งมาจาก ข้อมูลที่ส่งจะถูกบรรจุอยู่ในเนื้อหาของการร้องขอด้วย สิ่งนี้อาจทำให้เกิดการสร้างทรัพยากรใหม่ หรือการปรับปรุงทรัพยากรที่มีอยู่ หรือทั้งสองกรณี
- PUT
- อัปโหลดการนำเสนอของทรัพยากรที่ระบุ
- DELETE
- ลบทรัพยากรที่ระบุ
- TRACE
- ส่งข้อมูลร้องขอกลับมา เครื่องลูกข่ายจะเห็นว่ามีข้อมูลอะไรบ้างที่สื่อกลางเพิ่มหรือเปลี่ยนแปลงข้อความร้องขอก่อนไปถึงทรัพยากรปลายทาง
- OPTIONS
- คืนค่าเป็นรายชื่อคำสั่งเอชทีทีพีที่เครื่องแม่ข่ายนั้นรองรับสำหรับทรัพยากรที่ระบุ สิ่งนี้สามารถใช้ตรวจสอบฟังก์ชันการทำงานของเว็บเซิร์ฟเวอร์ได้โดยใส่ "*" แทนที่การระบุทรัพยากร
- CONNECT
- แปลงการเชื่อมต่อของการร้องขอไปเป็นทุนเนล TCP/IP แบบโปร่งใส มักใช้สำหรับแปลงการเชื่อมต่อที่เข้ารหัสแบบ SSL ให้เดินทางผ่านพร็อกซีที่ไม่มีการเข้ารหัสได้ง่ายขึ้น
คำสั่งที่ปลอดภัย
คำสั่งของเอชทีทีพีบางคำสั่งมีการกำหนดว่าเป็นคำสั่งที่ปลอดภัย เช่น HEAD, GET, OPTIONS, TRACE ซึ่งหมายความว่าคำสั่งเหล่านี้มีขึ้นเพื่อการรับข้อมูลเพียงอย่างเดียวและไม่ควรเปลี่ยนสถานะของเครื่องแม่ข่าย หรืออีกนัยหนึ่งคือคำสั่งเหล่านี้ไม่ควรทำให้เกิดผลกระทบข้างเคียง เว้นแต่ผลกระทบนั้นไม่สร้างความเสียหายอาทิ การบริการเว็บแบนเนอร์ หรือการเพิ่ม การร้องขอแบบ GET แบบไม่มีกฎเกณฑ์โดยอินเทอร์เน็ตบอตและเว็บครอว์เลอร์ จึงยังคงถือว่าปลอดภัยอยู่
ในทางตรงข้าม คำสั่ง POST, PUT, DELETE เป็นการกระทำเพื่อให้เกิดผลกระทบต่อเครื่องแม่ข่าย หรือเกิดผลกระทบภายนอกเช่นทำให้เกิดธุรกรรมทางการเงิน หรือการส่งอีเมลเป็นต้น จึงเป็นคำสั่งที่ไม่ปลอดภัย คำสั่งเช่นนี้ปกติจะไม่ถูกใช้โดยอินเทอร์เน็ตบอตและเว็บครอว์เลอร์ ซึ่งทำงานโดยไม่พิจารณาสถานะของเครื่องแม่ข่าย เพราะอาจทำให้ทรัพยากรเสียหายได้
รหัสสถานภาพ
ตั้งแต่ HTTP/1.0 เป็นต้นไป บรรทัดแรกของการตอบรับเอชทีทีพีเรียกว่า บรรทัดสถานภาพ (status line) ซึ่งประกอบด้วยตัวเลข รหัสสถานภาพ (status code เช่น 404) และข้อความ วลีเหตุผล (reason phrase เช่น "Not Found") โปรแกรมตัวแทนผู้ใช้จะพิจารณาการตอบรับในส่วนหัวโดยขึ้นอยู่กับรหัสสถานภาพเป็นหลัก และตามด้วยวลีเหตุผลเป็นรอง รหัสสถานภาพที่กำหนดขึ้นมาเองก็สามารถใช้ได้ ซึ่งหากตัวแทนผู้ใช้พบกับรหัสสถานภาพที่ไม่รู้จัก มันจะพิจารณาตัวเลขตัวแรกในรหัสเพื่อแยกประเภททั่วไปของการตอบรับ
รหัสสถานภาพของเอชทีทีพีแบ่งออกเป็นกลุ่มใหญ่ได้ห้ากลุ่มได้แก่
- 1xx ข้อมูลทั่วไป
- 2xx การร้องขอสำเร็จ
- 3xx การเปลี่ยนทาง
- 4xx ความผิดพลาดจากเครื่องลูกข่าย
- 5xx ความผิดพลาดจากเครื่องแม่ข่าย
การเชื่อมต่อแบบคงอยู่
ใน HTTP/0.9 และ 1.0 การเชื่อมต่อจะถูกปิดทุกครั้งหลังจากการการร้องขอและการตอบรับจบไป ดังนั้นในรุ่น HTTP/1.1 จึงมีการแนะนำกลไกเพื่อให้การเชื่อมต่อยังคงอยู่ ซึ่งจะทำให้การเชื่อมต่อเพียงครั้งเดียวสามารถใช้ซ้ำได้อีกเรื่อย ๆ มากกว่าหนึ่งครั้ง การเชื่อมต่อแบบคงอยู่เช่นนั้นช่วยลดโอกาสของการเกิดความล่าช้า (lag) เพราะว่าเครื่องลูกข่ายไม่จำเป็นต้องต่อรองการเชื่อมต่อทีซีพีใหม่อีกครั้ง หลังจากข้อความร้องขอแรกได้ถูกส่งไปแล้ว
HTTP/1.1 ได้มีการจัดแบนด์วิดท์ให้ดียิ่งขึ้นไปกว่ารุ่น 1.0 ยกตัวอย่างเช่น HTTP/1.1 มีการแนะนำการเข้ารหัสขนส่งเป็นชิ้นส่วน (chunked transfer encoding) เพื่อทำให้เนื้อหาบนการเชื่อมต่อแบบคงอยู่ส่งถ่ายเป็นได้ (streaming) แทนที่จะเก็บลงในที่พักข้อมูล (buffer) (HTTP pipelining) ก็เป็นอีกเทคนิคหนึ่งที่ช่วยลดความล่าช้าลงได้อย่างมาก ซึ่งทำให้เครื่องลูกข่ายสามารถส่งข้อความร้องขอได้หลายข้อความ ก่อนที่จะได้รับข้อความตอบรับของอันแรก อีกพัฒนาการหนึ่งคือ (byte serving) ซึ่งจะทำให้เครื่องแม่ข่ายส่งถ่ายข้อมูลมาเพียงแค่ส่วนหนึ่งจากทรัพยากรทั้งอัน ในช่วงตำแหน่งที่เครื่องลูกข่ายต้องการ
สถานะวาระของเอชทีทีพี
เอชทีทีพีเป็นโพรโทคอลที่ไม่มีการระบุสถานะ ข้อดีของโพรโทคอลแบบนี้คือเครื่องแม่ข่ายไม่จำเป็นต้องดึงสารสนเทศอื่นมาจากผู้ใช้ในระหว่างการร้องขอ แต่สิ่งนี้ทำให้ต้องใช้วิธีการอื่นเพื่อรักษาสถานะของผู้ใช้ ตัวอย่างเช่น ผู้ใช้ที่ต้องการปรับแต่งเนื้อหาเว็บไซต์ เว็บแอปพลิเคชันจะต้องบันทึกติดตามกระบวนการต่าง ๆ ของผู้ใช้เป็นหน้าต่อหน้า หรือการล็อกอินเข้าสู่ระบบ ซึ่งจำเป็นต้องทราบว่าผู้ใช้นั้นอยู่ในสถานะล็อกอินหรือไม่ จึงจะส่งข้อความตอบรับได้อย่างเหมาะสม วิธีการที่เป็นปกติสำหรับปัญหานี้คือการรับและส่งคุกกี้ และวิธีการอื่นคื่อการสร้างตัวแปรวาระ (session) ทางฝั่งเครื่องแม่ข่าย หรือใช้ตัวแปรซ่อนผ่านทางหน้าแบบฟอร์ม หรือใช้พารามิเตอร์ที่เข้ารหัสแบบตัวชี้แหล่งในอินเทอร์เน็ต (เช่น /index.php?session_id=some_unique_session_code)
อ้างอิง
- . คลังข้อมูลเก่าเก็บจากแหล่งเดิมเมื่อ 2017-07-15. สืบค้นเมื่อ 2009-05-09.
- http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-05.txt
- "Apache Week. HTTP/1.1". 090502 apacheweek.com
- HTTP 1.1 Section 5.1.1
- "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. สืบค้นเมื่อ 2007-05-10.
- 6.1 Status-Line
แหล่งข้อมูลอื่น
- HTTP จาก W3C
- Key Differences between HTTP/1.0 and HTTP/1.1
wikipedia, แบบไทย, วิกิพีเดีย, วิกิ หนังสือ, หนังสือ, ห้องสมุด, บทความ, อ่าน, ดาวน์โหลด, ฟรี, ดาวน์โหลดฟรี, mp3, วิดีโอ, mp4, 3gp, jpg, jpeg, gif, png, รูปภาพ, เพลง, เพลง, หนัง, หนังสือ, เกม, เกม, มือถือ, โทรศัพท์, Android, iOS, Apple, โทรศัพท์โมบิล, Samsung, iPhone, Xiomi, Xiaomi, Redmi, Honor, Oppo, Nokia, Sonya, MI, PC, พีซี, web, เว็บ, คอมพิวเตอร์
eknthwithikhnsngkhxkhwamhlaymiti hrux exchthithiphi xngkvs HyperText Transfer Protocol HTTP khuxophrothkhxlinradbchnopraekrmprayuktephuxkaraeckcayaelakarthanganrwmknkbsarsnethskhxngsuxphsm ichsahrbkarrbthrphyakrthiechuxmoyngkbphaynxk sungnaipsukarcdtngewildiwdewbexchthithiphimatrthansaklRFC 1945 HTTP 1 0 RFC 9110 HTTP Semantics RFC 9111 HTTP Caching RFC 9112 HTTP 1 1 RFC 9113 RFC 7541 HTTP 2 HPACK Header Compression RFC 8164 HTTP 2 Opportunistic Security for HTTP 2 RFC 8336 HTTP 2 The ORIGIN HTTP 2 Frame RFC 8441 HTTP 2 Bootstrapping WebSockets with HTTP 2 RFC 9114 RFC 9204 HTTP 3 QPACK Field Compressionphuphthnaerimtnody CERN IETF W3Crierim1991 33 pithiaelw 1991 ewbisthttps httpwg org specs karphthnaexchthithiphiepnkarthanganrwmknkhxngewildiwdewbkhxnsxrethiym W3C aelakhnathanganechphaakicdanwiswkrrmxinethxrent IETF sungmiphlnganedninkarephyaephrexksarkhxkhwamehn RFC hlaychud exksarthisakhythisudkhux RFC 2616 eduxnmithunayn ph s 2542 idkahnd HTTP 1 1 sungepnrunthiichknxyangkwangkhwanginpccubn exchthithiphiepnmatrthaninkarrxngkhxaelakartxbrbrahwangekhruxnglukkhaykbekhruxngaemkhay sungekhruxnglukkhaykhuxphuichplaythang end user aelaekhruxngaemkhaykhuxewbist ekhruxnglukkhaycasrangkarrxngkhxexchthithiphiphanthangewbebrawesxr ewbkhrxwelxr hruxekhruxngmuxxun thicdwaepn user agent swnekhruxngaemkhaythitxbrb sungekbbnthukhruxsrang thrphyakr resource xyangechniflexchthiexmaexlhruxrupphaph caeriykwa ekhruxngihbrikartnthang origin server inrahwangtwaethnphuichkbekhruxngihbrikartnthangxacmisuxklanghlaychnid xathiphrxksi ektewy aela exchthithiphiimidcakdwacatxngich TCP IP ethann aemwacaepnkarichnganthiniymmakthisudbnxinethxrentktam odyaethcringaelwexchthithiphisamarth naipichidbnophrothkhxlxinethxrentxun hruxbnekhruxkhayxunkid exchthithiphikhadhwngephiyngaekhkarsuxsarthiechuxthuxid nnkhuxophrothkhxlthimikarrbrxngechnnnksamarthichnganid pktiekhruxnglukkhayexchthithiphicaepnphuerimsrangkarrxngkhxkxn odyepidkarechuxmtxdwyeknthwithikhwbkhumkarkhnsngkhxmul TCP ipyngechphaakhxngekhruxngaemkhay phxrt 80 epnkhapriyay ekhruxngaemkhayexchthithiphithiepidrxrbxyuthiphxrtnn caepidrxihekhruxnglukkhaysngkhxkhwamrxngkhxekhama emuxidrbkarrxngkhxaelw ekhruxngaemkhaycatxbrbdwykhxkhwamsthanaxnhnung twxyangechn HTTP 1 1 a href wiki 200 title 200 200 a OK tamdwyenuxhakhxngmnexngsngipdwy enuxhannxacepnaefmkhxmulthirxngkhx khxkhwamaesdngkhxphidphlad hruxkhxmulxyangxunepntn thrphyakrthithukekhathungdwyexchthithiphicathukrabuodyich URI hruxecaacnglngipkkhux twchiaehlnginxinethxrent URL odyich http hrux https epn URI scheme khxkhwamrxngkhxkhxkhwamrxngkhxprakxbdwysingtxipni brrthdaerk khuntnepnkhasngrxngkhx aelaesnthangiderkthxrikhxngaefmthirxngkhx tamdwyrunkhxng HTTP twxyangechn GET images logo gif HTTP 1 1 brrthdtx ipthiimichbrrthdwang eriykwaepn swnhw header epnemthaedtatang prakxbkarrxngkhx twxyangechn Accept Language en brrthdwang ephuxaebngaeykrahwangswnhwkbenuxha brrthdtx ip epnenuxhakhxmul sungbangkhasngxacimcaepntxngichswnni aetlabrrthdcatxnglngthaydwy CRLF xkkhratamdwyxkkhra ehmuxnkarkdpum Enter inwinodws brrthdthiwangcamiephiyngaekh CRLF ethannodyimmixkkhrachxngwangxyuely sahrbrun HTTP 1 1 swnhw Host caepntxngmiesmx aetswnhwxun imcaepntxngmikid brrthdkhasngthimiephiyngesnthangiderkthxri immichuxaefm kepnthiyxmrbodyekhruxngaemkhay ephuxrksakhwamekhaknidkbopraekrmtwaethnrunekakxnthicamikhxkahndkhxng HTTP 1 0 in RFC 1945 swn HTTP 1 1 idkahndiwin RFC 2068khasngrxngkhxtwxyangkhxkhwamrxngkhxexchthithiphithisranginethlent ennsiswnhwaelaswnenuxhakhxngthngkhxkhwamrxngkhxaelakhxkhwamtxbrb exchthithiphiidkahndkhasngrxngkhxiwaepdkhasng hruxeriykwawithikarrxngkhx bangkhrngxaceriykwaepn kriya aesdngkarkrathathitxngkar ephuxthicadaeninkarkbthrphyakrthithukrabu singthithrphyakrnnnaesnx imwaepnkhxmulthimixyukxnhruxsrangkhunmaaebbphlwtktam cakhunxyukbkarnaipichkhxngekhruxngaemkhay sungbxykhrngthrphyakrmkcasxdkhlxngkbifl hruxphllphthsngxxkcakopraekrmkhangekhiynginekhruxngaemkhaynn ekhruxngihbrikarexchthithiphicatxngsamarthichkhasng GET aela HEAD idepnxyangnxy HEAD rxngkhxkartxbrbcakthrphyakrthirabu khlaykb GET aetcaimmiswnenuxhathirxngkhxklbma khasngniichpraoychninkartrwcsxbkhxmulswnhwkhxngkartxbrb odyimcaepntxngsngenuxhaetmmathnghmd GET rxngkhxkarnaesnxcakthrphyakrthirabu khasngniimkhwrichkbkardaeninkarthixacthaihekidphlkhangekhiyng echnkarcdkarinewbaexpphliekhchn ehtuphlhnungkhuxkhasng GET mkcathukichxyangimmikdeknthodyxinethxrentbxtaelaewbkhrxwelxr sungimkhwrphicarnaihkarrxngkhxkhxngbxtaelakhrxwelxrsngphlkrathbtxthrphyakrinewb duephimthihwkhx khasngthiplxdphy POST sngkhxmulipyngthrphyakrthirabuephuxihnaippramwlphl odyechphaakhxmulthisngmacak khxmulthisngcathukbrrcuxyuinenuxhakhxngkarrxngkhxdwy singnixacthaihekidkarsrangthrphyakrihm hruxkarprbprungthrphyakrthimixyu hruxthngsxngkrni PUT xpohldkarnaesnxkhxngthrphyakrthirabu DELETE lbthrphyakrthirabu TRACE sngkhxmulrxngkhxklbma ekhruxnglukkhaycaehnwamikhxmulxairbangthisuxklangephimhruxepliynaeplngkhxkhwamrxngkhxkxnipthungthrphyakrplaythang OPTIONS khunkhaepnraychuxkhasngexchthithiphithiekhruxngaemkhaynnrxngrbsahrbthrphyakrthirabu singnisamarthichtrwcsxbfngkchnkarthangankhxngewbesirfewxridodyis aethnthikarrabuthrphyakr CONNECT aeplngkarechuxmtxkhxngkarrxngkhxipepnthunenl TCP IP aebboprngis mkichsahrbaeplngkarechuxmtxthiekharhsaebb SSL ihedinthangphanphrxksithiimmikarekharhsidngaykhunkhasngthiplxdphy khasngkhxngexchthithiphibangkhasngmikarkahndwaepnkhasngthiplxdphy echn HEAD GET OPTIONS TRACE sunghmaykhwamwakhasngehlanimikhunephuxkarrbkhxmulephiyngxyangediywaelaimkhwrepliynsthanakhxngekhruxngaemkhay hruxxiknyhnungkhuxkhasngehlaniimkhwrthaihekidphlkrathbkhangekhiyng ewnaetphlkrathbnnimsrangkhwamesiyhayxathi karbrikarewbaebnenxr hruxkarephim karrxngkhxaebb GET aebbimmikdeknthodyxinethxrentbxtaelaewbkhrxwelxr cungyngkhngthuxwaplxdphyxyu inthangtrngkham khasng POST PUT DELETE epnkarkrathaephuxihekidphlkrathbtxekhruxngaemkhay hruxekidphlkrathbphaynxkechnthaihekidthurkrrmthangkarengin hruxkarsngxiemlepntn cungepnkhasngthiimplxdphy khasngechnnipkticaimthukichodyxinethxrentbxtaelaewbkhrxwelxr sungthanganodyimphicarnasthanakhxngekhruxngaemkhay ephraaxacthaihthrphyakresiyhayidrhssthanphaphtngaet HTTP 1 0 epntnip brrthdaerkkhxngkartxbrbexchthithiphieriykwa brrthdsthanphaph status line sungprakxbdwytwelkh rhssthanphaph status code echn 404 aelakhxkhwam wliehtuphl reason phrase echn Not Found opraekrmtwaethnphuichcaphicarnakartxbrbinswnhwodykhunxyukbrhssthanphaphepnhlk aelatamdwywliehtuphlepnrxng rhssthanphaphthikahndkhunmaexngksamarthichid sunghaktwaethnphuichphbkbrhssthanphaphthiimruck mncaphicarnatwelkhtwaerkinrhsephuxaeykpraephththwipkhxngkartxbrb rhssthanphaphkhxngexchthithiphiaebngxxkepnklumihyidhaklumidaek 1xx khxmulthwip 2xx karrxngkhxsaerc 3xx karepliynthang 4xx khwamphidphladcakekhruxnglukkhay 5xx khwamphidphladcakekhruxngaemkhaykarechuxmtxaebbkhngxyuin HTTP 0 9 aela 1 0 karechuxmtxcathukpidthukkhrnghlngcakkarkarrxngkhxaelakartxbrbcbip dngnninrun HTTP 1 1 cungmikaraenanaklikephuxihkarechuxmtxyngkhngxyu sungcathaihkarechuxmtxephiyngkhrngediywsamarthichsaidxikeruxy makkwahnungkhrng karechuxmtxaebbkhngxyuechnnnchwyldoxkaskhxngkarekidkhwamlacha lag ephraawaekhruxnglukkhayimcaepntxngtxrxngkarechuxmtxthisiphiihmxikkhrng hlngcakkhxkhwamrxngkhxaerkidthuksngipaelw HTTP 1 1 idmikarcdaebndwidthihdiyingkhunipkwarun 1 0 yktwxyangechn HTTP 1 1 mikaraenanakarekharhskhnsngepnchinswn chunked transfer encoding ephuxthaihenuxhabnkarechuxmtxaebbkhngxyusngthayepnid streaming aethnthicaekblnginthiphkkhxmul buffer HTTP pipelining kepnxikethkhnikhhnungthichwyldkhwamlachalngidxyangmak sungthaihekhruxnglukkhaysamarthsngkhxkhwamrxngkhxidhlaykhxkhwam kxnthicaidrbkhxkhwamtxbrbkhxngxnaerk xikphthnakarhnungkhux byte serving sungcathaihekhruxngaemkhaysngthaykhxmulmaephiyngaekhswnhnungcakthrphyakrthngxn inchwngtaaehnngthiekhruxnglukkhaytxngkarsthanawarakhxngexchthithiphiexchthithiphiepnophrothkhxlthiimmikarrabusthana khxdikhxngophrothkhxlaebbnikhuxekhruxngaemkhayimcaepntxngdungsarsnethsxunmacakphuichinrahwangkarrxngkhx aetsingnithaihtxngichwithikarxunephuxrksasthanakhxngphuich twxyangechn phuichthitxngkarprbaetngenuxhaewbist ewbaexpphliekhchncatxngbnthuktidtamkrabwnkartang khxngphuichepnhnatxhna hruxkarlxkxinekhasurabb sungcaepntxngthrabwaphuichnnxyuinsthanalxkxinhruxim cungcasngkhxkhwamtxbrbidxyangehmaasm withikarthiepnpktisahrbpyhanikhuxkarrbaelasngkhukki aelawithikarxunkhuxkarsrangtwaeprwara session thangfngekhruxngaemkhay hruxichtwaeprsxnphanthanghnaaebbfxrm hruxichpharamietxrthiekharhsaebbtwchiaehlnginxinethxrent echn index php session id some unique session code xangxing khlngkhxmulekaekbcakaehlngedimemux 2017 07 15 subkhnemux 2009 05 09 http www ietf org internet drafts draft ietf httpbis p1 messaging 05 txt Apache Week HTTP 1 1 090502 apacheweek com HTTP 1 1 Section 5 1 1 Vulnerability Note VU 150227 HTTP proxy default configurations allow arbitrary TCP connections US CERT 2002 05 17 subkhnemux 2007 05 10 6 1 Status LineaehlngkhxmulxunHTTP cak W3C Key Differences between HTTP 1 0 and HTTP 1 1bthkhwamkhxmphiwetxr xupkrntang hruxekhruxkhayniyngepnokhrng khunsamarthchwywikiphiediyidodykarephimetimkhxmuldkhk