คำถามติดแท็ก http-headers

ใน Hypertext Transfer Protocol (HTTP) ฟิลด์ส่วนหัว HTTP มีพารามิเตอร์การทำงานของคำร้องขอหรือการตอบกลับ HTTP ด้วยคำขอหรือบรรทัดตอบกลับ (บรรทัดแรกของข้อความ) จะสร้างส่วนหัวของข้อความ

5
ความแตกต่างระหว่างส่วนหัว Accept และ Content-Type HTTP
ดังนั้นAcceptส่วนหัวจะบอกเซิร์ฟเวอร์ประเภท MIME ของทรัพยากรที่เบราว์เซอร์กำลังมองหา ตัวอย่างเช่นเซิร์ฟเวอร์สามารถส่งข้อความธรรมดา, HTML, JSON เป็นต้น ตกลงที่เหมาะสม แต่เมื่อฉันดูที่Content-Typeส่วนหัวและดูเหมือนว่าจะทำสิ่งเดียวกัน ตัวอย่างเช่นมันบอกเซิร์ฟเวอร์ว่ามันต้องการข้อความหรือ JSON ดังนั้นความแตกต่างระหว่างAcceptและContent-Typeส่วนหัว HTTP คืออะไร?

5
ส่วนหัวเพื่อป้องกันคำขอ 304 / If-modified-since / HEAD
ฉันควรส่งส่วนหัวใดให้หยุดการร้องขอทั้งหมดไปยังเซิร์ฟเวอร์ทันทีหลังจากที่เนื้อหาถูกแคช เรามีเซิร์ฟเวอร์เวลาในการตอบสนองสูง (ถอนหายใจ, VMWare) ดังนั้นแม้การส่งHEADคำขอไปยังเซิร์ฟเวอร์จะใช้เวลา + 40ms ขณะนี้เหล่านี้เป็นส่วนหัวที่ถูกส่ง / รับ; ขอครั้งแรก ลูกค้าส่ง; GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1 Host: dugong:8080 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Pragma: no-cache, no-cache, no-cache Cache-Control: no-cache, no-cache, no-cache เซิร์ฟเวอร์ตอบสนอง; HTTP/1.1 200 OK Server: nginx/1.0.11 Date: Wed, …

1
ขนาดวัตถุขั้นต่ำที่แนะนำสำหรับประโยชน์ของประสิทธิภาพการทำงานของ gzip คืออะไร?
ฉันกำลังปรับปรุงเวลาในการแสดงหน้าความเร็วและวิธีหนึ่งคือการ gzip เนื้อหาจากเว็บเซิร์ฟเวอร์ Google แนะนำ : โปรดทราบว่า gzipping จะเป็นประโยชน์สำหรับทรัพยากรที่มีขนาดใหญ่ เนื่องจากโอเวอร์เฮดและเวลาแฝงของการบีบอัดและคลายการบีบอัดคุณควร gzip ไฟล์ที่เกินขีด จำกัด ขนาดที่แน่นอน เราแนะนำช่วงต่ำสุดระหว่าง 150 ถึง 1,000 ไบต์ การขยายไฟล์ที่มีขนาดต่ำกว่า 150 ไบต์สามารถทำให้ไฟล์มีขนาดใหญ่ขึ้นได้ เราให้บริการเนื้อหาของเราผ่านAkamaiโดยใช้เครือข่ายของพวกเขาสำหรับพร็อกซีและ CDN สิ่งที่พวกเขาบอกฉัน: การติดตามคำถามของคุณเกี่ยวกับขนาดที่เล็กที่สุด Akamai จะบีบอัดวัตถุที่ร้องขอเมื่อส่งไปยังผู้ใช้ปลายทาง: ขนาดต่ำสุดคือ 860 ไบต์ คำตอบของฉัน: ทำไมขนาดขั้นต่ำของ Akamai คือ 860 ไบต์คืออะไร และทำไมตัวอย่างเช่นกรณีนี้ไม่ใช่สำหรับไฟล์ที่ Akamai ใช้กับ Facebook? ( ดูด้านล่าง ) Google แนะนำให้ gzip มากยิ่งขึ้น และดูเหมือนว่าเหมาะสมในไซต์ของเราที่มีจำนวนการเข้าชมบ่อยที่สุดคือการโทร AJAX …

2
ผลที่ตามมาสำหรับการใช้ส่วนหัวสถานที่สัมพันธ์คืออะไร?
ตามข้อมูลจำเพาะส่วนหัวสถานที่ที่ใช้ในการเปลี่ยนเส้นทางจำเป็นต้องใช้ชื่อเซิร์ฟเวอร์ HTTP/1.1 301 Moved Permanently ... Location: http://example.com/foo/baz/bar อย่างไรก็ตามในปี 2012 เว็บเบราว์เซอร์ส่วนใหญ่จะรู้จักเส้นทางที่สัมพันธ์กันและนำคุณไปยังตำแหน่งใหม่โดยใช้ชื่อเซิร์ฟเวอร์ดั้งเดิม HTTP/1.1 301 Moved Permanently ... Location: /foo/baz/bar มีผลกระทบด้านลบ / ที่น่าประหลาดใจต่อการใช้ URL สัมพัทธ์ในส่วนหัวสถานที่ตั้งหรือไม่? ข้อกังวลโดยเฉพาะของฉันคือวิธีที่ Google / เครื่องมือค้นหาจะตีความสิ่งนี้ แต่ถ้ามีอะไรอีกที่ฉันไม่คิดว่าฉันชอบที่จะได้ยิน

2
แบบอักษรถูกปิดกั้นไม่ให้โหลดโดยนโยบายการแบ่งปันทรัพยากรข้ามแหล่งกำเนิด: ไม่มี 'การเข้าถึงการควบคุมการอนุญาต - แหล่งกำเนิด'
เราพบข้อผิดพลาดนี้ใน Google Chrome เราคิดว่าทุกอย่างถูกต้องแล้ว แต่อาจจะไม่ แบบอักษรจากแหล่งกำเนิดhttp://skin.cdn.comถูกบล็อกไม่ให้โหลดโดยนโยบายการแชร์ทรัพยากรข้ามแหล่งกำเนิด: ไม่มีส่วนหัว 'การเข้าถึงการควบคุมการอนุญาตให้มีแหล่งกำเนิด' ปรากฏบนทรัพยากรที่ร้องขอ Origin http://domain2.comไม่อนุญาตให้เข้าถึง และเรามีสิ่งต่อไปนี้ใน htaccess (ในรูทของโดเมน) <IfModule mod_headers.c> Header add Access-Control-Allow-Origin "http://skin.cdn.com" </IfModule> คำถาม:ฉันลืมการตั้งค่าอื่น ๆ ได้ไหม? ขอบคุณมาก

1
ไม่ได้ระบุชุดอักขระในข้อผิดพลาดส่วนหัว HTTP
เมื่อทดสอบหน้านี้ด้วย Page Speed ​​ฉันพบSpecify a character setข้อผิดพลาด: The following resources have no character set specified in their HTTP headers. Specifying a character set in HTTP headers can speed up browser rendering. Content-Typeแท็กเป็นปัจจุบันและหน้าได้รับการบันทึกไว้กับ UTF-8 เข้ารหัสเช่นกันดังนั้นที่เป็นข้อผิดพลาดมาจากไหน

1
อะไรคือวิธีที่ดีที่สุดในการจบเว็บไซต์
ฉันมีเว็บไซต์ที่สร้างขึ้นบน ASP.NET MVC 3 ซึ่งจะปิดตัวลงอย่างสมบูรณ์ โดเมนจะยังคงถูกต้องสำหรับสองสามเดือนดังนั้นในช่วงเวลานั้นฉันต้องการแสดงข้อความเดียวในหน้าหลักอย่างน้อย ฉันคิดว่ามาตรฐานจะกำหนดให้คำขอทั้งหมดส่งไปที่หน้าเดียวผ่าน 301 ย้ายอย่างถาวรหรือรับ 410 Gone สำหรับคำขอทั้งหมด นี่เป็นครั้งแรกที่ฉันปิดเว็บไซต์อย่างสมบูรณ์และในขณะที่ฉันหวังว่าฉันจะไม่ต้องทำมันอีกในเร็ว ๆ นี้ฉันอยากจะรู้วิธีที่เหมาะสมในการทำสิ่งนี้ (ฉันเปิดกว้างสำหรับการแนะนำแท็กการปิดเว็บไซต์ดูเหมือนจะไม่เป็นหัวข้อยอดนิยมซึ่งฉันคิดว่าเป็นเรื่องที่ดี)

2
ข้อควรพิจารณาของ HTTP Content-MD5 Header
เรากำลังถกเถียงกันว่าจะใช้ส่วนหัวของ Content-MD5 หรือไม่ ข้อดี: CMS ช่วยให้เราสามารถรวมกับค่าใช้จ่ายน้อยที่สุด (การตอบสนองที่แคชไว้ใน 80% + ของกรณี) มันจะเพิ่มอีกชั้นของการป้องกันปัญหา จุดด้อย: ส่วนหัวความยาวเนื้อหามีอยู่เสมอ (แม้ในหน้าเว็บที่สร้างขึ้นแบบไดนามิก) ดังนั้นลูกค้าไม่ควรต้องการการตรวจสอบความถูกต้องรูปแบบอื่น จนถึงตอนนี้เราไม่ทราบถึงปัญหาใด ๆ ที่เกิดจากการทุจริต MD5 ตรวจสอบเพิ่มเวลาแฝงในการโหลดหน้าเว็บ คะแนน: สื่อบางประเภทมีรูปแบบการแยกย่อยของตนเองที่ไม่จำเป็นหรือไม่? หาก TCP เสนอสิ่งนี้แล้วทำไมมันจึงรวมอยู่ในมาตรฐาน HTTP สิ่งที่มีอยู่ในชีวิตจริงใช้คืออะไร? การตรวจสอบ MD5 นั้นเล็กน้อยหรือไม่? ไม่มีปัญหาจริงสำหรับการเพิ่มลงในการทดสอบหน่วยและใช้งานเกี่ยวกับชั่วโมงทำงาน อย่างไรก็ตามหากมันเป็นอันตรายเราต้องการให้มันเพิ่มการทดสอบสูดดมในระดับที่สูงขึ้นที่ใช้ในเว็บไซต์ "ตรวจสุขภาพ"

1
หากฉันแสดงเฉพาะเนื้อหาในเวอร์ชัน gzipped ฉันควรเพิ่มส่วนหัวการเข้ารหัสที่หลากหลายยอมรับ
ฉันเพิ่งย้ายไซต์แบบคงที่จาก VPS ไปยัง Amazon S3 ฉันตัดสินใจที่จะให้บริการเฉพาะหน้าเว็บในเวอร์ชัน gzipped เนื่องจาก S3 ไม่ใช่เว็บเซิร์ฟเวอร์ฉันไม่สามารถใช้ตรรกะตามส่วนหัวได้ ฉันยังใช้ Cloudfront เป็น CDN ฉันถูกทดสอบหน้าของฉันกับhttp://gtmetrix.com/vary accept encoding headerและได้ทราบดีเพราะผมไม่ได้เพิ่ม ดังนั้นฉันจึงตรวจสอบสิ่งนี้เกี่ยวกับและเท่าที่ฉันเข้าใจมันเหมาะสมเมื่อเราให้บริการทั้งรุ่นบีบอัดและไม่บีบอัด ดังนั้นฉันต้องการให้คุณช่วยฉันอธิบายเรื่องนี้ ฉันควรจะเพิ่มหรือไม่ ขอบคุณ :)

2
ส่วนหัว 'เซิร์ฟเวอร์' รองรับวัตถุประสงค์ใด ๆ
ตัวอย่างเช่นเมื่อฉันถ่ายโอนส่วนหัวการตอบกลับสำหรับเซิร์ฟเวอร์ของฉันฉันจะได้รับ: Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch mod_ssl/2.2.11 OpenSSL/0.9.8g มันใช้เพื่ออะไร มันเสี่ยงด้านความปลอดภัยหรือไม่

2
เหตุใดจึงใช้“ 29030400” วินาทีเป็นค่าทั่วไปสำหรับการหมดอายุของแคช
ฉันสังเกตเห็นว่า 29030400 มีการใช้บ่อยมากในคำสั่งหมดอายุสำหรับไฟล์คงที่ Google แนะนำให้แคชไฟล์ประเภทนี้นานถึง 1 ปี (อย่างน้อย 1 เดือน) ฉันทำคณิตศาสตร์: 29030400 วินาที = 336 วัน นั่นคือประมาณ 1 ปีลบ 1 เดือนดังนั้นจึงตกอยู่ในช่วงเวลาที่แนะนำอย่างสมบูรณ์ แต่คำถามคือว่าทำไม 29030400? และไม่ใช่ 31536000 วินาที = 365 วันเป็นตัวอย่าง? เพียงแค่คัดลอก / วางค่าที่ตั้งแบบสุ่มในวันเก่า? หรือมีคำอธิบายอื่น

3
เนื้อหาที่หมดอายุควรจัดการอย่างไร?
ลองจินตนาการถึงกรณีที่ง่ายกว่านี้: เว็บไซต์การประมูลมีหน้า "รายละเอียดการประมูล" ไม่กี่สัปดาห์หลังจากการประมูลสิ้นสุดลงหน้า "รายละเอียดการประมูล" จะไม่สามารถใช้งานได้อีก เราเพียงแค่ให้บริการHTTP/1.1 410 Goneกับหน้าเว็บที่ให้เหตุผล อย่างไรก็ตามคู่แข่งของเราเล่นแตกต่างกัน (แม้แต่อีเบย์) ... เมื่อเนื้อหาถูกลบพวกเขาจะให้บริการHTTP/1.1 301 Moved Permanentlyและเปลี่ยนเส้นทางไปยังรายการหมวดหมู่ที่เกี่ยวข้องกับการประมูล ความสะอาดของกลยุทธ์เปลี่ยนเส้นทาง 301 นี้คืออะไร (สำหรับเราดูเหมือนว่า seo สีเทา / ดำ) กลยุทธ์ที่ดีที่สุดคืออะไร? โปรดทราบ : เมื่อผู้ใช้ลบการประมูลของเราเราจะไม่สามารถปล่อยให้เนื้อหาเข้าถึงได้ (แม้จะผ่านการเชื่อมโยงโดยตรง) เนื่องจากข้อมูลบางอย่างนั้นเป็น "ยุทธศาสตร์" หรือข้อมูลที่ไม่แน่นอน

2
จะเกิดอะไรขึ้นเมื่อลบเนื้อหา
ฉันสงสัยเกี่ยวกับการจัดการมาตรฐานของลิงก์ข้อมูลที่ถูกลบจากแอปพลิเคชันและมุมมอง SEO ฉันมีแอปพลิเคชันที่ผู้ใช้สามารถสร้างเนื้อหา แต่พวกเขายังสามารถลบเนื้อหา วิธีที่ดีที่สุดในการจัดการทราฟฟิกขาเข้าไปยังลิงก์ที่ถูกลบไปแล้วคืออะไร? ฉันควรเปลี่ยนเส้นทางไปยังที่ใดที่หนึ่งด้วย 301 หรือฉันควรโยนข้อผิดพลาดที่แตกต่างกันออกไป

4
จะบอกเบราว์เซอร์เกี่ยวกับการเข้ารหัสอักขระของเว็บไซต์ HTML ได้อย่างไรไม่ว่าส่วนหัวของเซิร์ฟเวอร์เนื้อหาประเภทใด
ฉันมีหน้า HTML ที่ถูกต้อง (การเข้ารหัสของฟิสิคัลบนดิสก์ตรงกับมัน) ประกาศว่าเป็นประเภทเนื้อหา : <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content= "text/html; charset=utf-8"> <title> ... เปิดไฟล์จากดิสก์ในเบราว์เซอร์ (Google Chrome, Firefox) ทำงานได้ดี เมื่อร้องขอผ่าน HTTP เว็บเซิร์ฟเวอร์จะส่งส่วนหัว Content-Type อื่น: $ curl -I http://example.com/file.html HTTP/1.1 200 OK Date: Fri, 19 Oct 2012 10:57:13 GMT ... Content-Type: text/html; charset=ISO-8859-1 …

2
จะใช้เมื่อใดและไม่ใช้ ETags
ฉันแค่ดูที่เว็บไซต์ของเราบนWebPageTest.orgและหนึ่งในคำแนะนำของพวกเขาสำหรับการเร่งเว็บไซต์คือ: โดยทั่วไปไม่ควรใช้ส่วนหัว ETag เว้นแต่คุณจะมีเหตุผลที่ชัดเจนในการต้องการ ฉันสงสัยว่าสิ่งนี้หมายความว่าอย่างไร หมายความว่าเนื้อหาแบบคงที่คุณรู้ว่าจะไม่เปลี่ยนแปลงไม่ควรมีหรือหมายความว่าเนื้อหาที่คุณรู้ว่าจะมีการเปลี่ยนแปลงอย่างสม่ำเสมอไม่ควรมีหรือหมายความว่าคุณไม่ควรใช้งานโดยทั่วไปเว้นแต่คุณจะมี ความต้องการเฉพาะ ถ้าเป็นหลังเวลาที่เหมาะสมในการใช้งานคือเมื่อใด ขอบคุณสำหรับความช่วยเหลือ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.