1. Biblioteca
  2. HTTP והרשת
  3. קודי סטטוס HTTP

Atualizado há 1 mês

כל שאר קודי הסטטוס של HTTP הם נקודה בסוף משפט. קודי 1xx הם פסיקים.

תגובות מידעיות אלה אומרות: "קיבלתי את הבקשה שלך, אני עובד עליה, אבל עדיין לא סיימתי." בשונה מ-200 או 404, תגובת 1xx לא מסיימת את תהליך ה-HTTP — היא עדכון ביניים, שתמיד מלווה בקוד סטטוס סופי.

לעיתים נדירות תראה אותם ישירות. אבל הם פועלים מתחת לפני השטח, ומאפשרים כמה מהטריקים החכמים ביותר של HTTP.

100 Continue: "אתה בטוח?"

דמיין שאתה עומד להעלות סרטון של 1GB. אתה לוחץ על שלח. הקובץ מתחיל להיטען. שלושים שניות לאחר מכן, השרת מגיב: 401 Unauthorized.

בזבזת רוחב פס וזמן על העלאת נתונים שהשרת לא היה מתכוון לקבל מלכתחילה.

פרוטוקול 100 Continue מונע זאת. זה HTTP ששואל "אתה בטוח?" לפני שאתה מתחייב:

הלקוח שולח כותרות בלבד:

POST /api/upload HTTP/1.1
Host: example.com
Authorization: Bearer token123
Content-Length: 1073741824
Expect: 100-continue

השרת בודק את הכותרות. האם הטוקן תקין? האם יש מקום לקובץ הזה? האם סוג התוכן מקובל?

אם הכל נראה תקין:

HTTP/1.1 100 Continue

עכשיו הלקוח שולח את גוף הבקשה של 1GB.

אם משהו לא בסדר:

HTTP/1.1 401 Unauthorized

הלקוח לא שולח את הגוף כלל. גיגה-בייט של רוחב פס נחסך.

רוב ספריות ה-HTTP מטפלות בזה אוטומטית עבור העלאות גדולות. הכותרת Expect: 100-continue מפעילה את המנגנון. אתה נהנה ממנו בלי לכתוב קוד מיוחד.

101 Switching Protocols: "בוא נדבר בשפה אחרת"

HTTP הוא פרוטוקול של בקשה-תגובה. הלקוח שואל, השרת עונה. אבל מה אם אתה צריך תקשורת דו-כיוונית בזמן אמת — אפליקציית צ'אט, עדכונים חיים, משחקי רשת מרובי משתתפים?

אתה מתחיל עם HTTP, ואז עובר למשהו אחר.

הלקוח מבקש שדרוג ל-WebSocket:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

השרת מסכים:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

לאחר חילופין אלה, החיבור כבר אינו HTTP. זה WebSocket — תקשורת דו-כיוונית מלאה, כל צד יכול לשלוח הודעות בכל עת.

לעולם לא תכתוב את הקוד הזה בעצמך. ספריות WebSocket מטפלות בכך. אבל כשאתה רואה 101 Switching Protocols בבודק הרשת שלך במהלך חיבור WebSocket, עכשיו אתה יודע מה קרה: HTTP פינה את מקומו בנימוס.

103 Early Hints: "התחל לטעון את אלה"

זה עניין של ביצועים. הנה הבעיה:

השרת שלך צריך 200ms לשאילתת בסיס נתונים ורינדור HTML. הדפדפן לא יכול להתחיל לטעון CSS ו-JavaScript עד שהוא מקבל ומנתח את ה-HTML הזה. זה 200ms של בזבוז שבו הדפדפן יושב בחוסר מעש.

103 Early Hints מאפשר לשרת לומר "אני עדיין עובד, אבל התחל לטעון את אלה":

מיידית, לפני שה-HTML מוכן:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </main.js>; rel=preload; as=script

הדפדפן מתחיל לאחזר את המשאבים האלה בזמן שהשרת עדיין מבצע שאילתה לבסיס הנתונים.

200ms מאוחר יותר, התגובה האמיתית:

HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <link rel="stylesheet" href="/style.css">
  <script src="/main.js"></script>
  ...
</html>

עד שהדפדפן מנתח את ה-HTML, ה-CSS וה-JavaScript כבר נטענים — או שכבר נטענו.

Early Hints זוהרים כשעיבוד השרת איטי ואתה יודע מראש אילו משאבים הדף יצטרך. הדפדפן עושה עבודה שימושית בזמן שאחרת היה עצור לשווא.

תמיכת הדפדפנים הולכת וגדלה. Chrome ו-Edge תומכים בה במלואה. דפדפנים שאינם מבינים 103 פשוט מתעלמים ממנו — ללא כל נזק.

לא תראה אותם

בקוד האפליקציה שלך, תגובות 1xx הן בלתי נראות:

const response = await fetch('/api/upload');
console.log(response.status); // 200, 404, 500... never 100 or 103

הדפדפן מטפל בהן ברמה נמוכה יותר. ה-fetch API חושף רק את התגובה הסופית.

חיבורי WebSocket מסתירים את ה-101:

const socket = new WebSocket('wss://example.com/chat');
// שדרוג הפרוטוקול התרחש. מעולם לא ראית אותו.

כדי לראות תגובות 1xx, השתמש בכלי הפיתוח של הדפדפן (בדוק את פרטי התגובה בכרטיסיית Network) או בכלי שורת פקודה כמו curl עם -v לפלט מפורט.

מדוע הם חשובים

קודי 1xx פותרים בעיות אמיתיות:

100 Continue חוסך רוחב פס בהעלאות הנידונות לכישלון. למה לשלוח גיגה-בייט אם השרת יידחה אותו על בסיס הכותרות בלבד?

101 Switching Protocols מאפשר את האינטרנט בזמן אמת. כל חיבור WebSocket מתחיל כאן.

103 Early Hints גורם לדפים לטעון מהר יותר על ידי הפעלת השרת והדפדפן במקביל.

הם גם מראים כיצד HTTP מתפתח בחן. על ידי שמירת קטגוריה לתגובות ביניים, הפרוטוקול יכול להוסיף קודים חדשים מבלי לשבור לקוחות קיימים. דפדפן שאינו מבין 103 פשוט מתעלם ממנו וממתין לתגובה הסופית.

כנראה לא תממש טיפול מותאם אישית ב-1xx. אבל אתה נהנה ממנו כל הזמן — כל חיבור WebSocket, כל העלאה גדולה, כל דף שנטען מעט מהר יותר כי הרמזים הגיעו לפני הזמן.

שאלות נפוצות על קודי סטטוס 1xx

מדוע אני לא רואה תגובות 1xx בקוד JavaScript שלי?

דפדפנים מטפלים בתגובות 1xx ברמה נמוכה יותר מה-fetch API או XMLHttpRequest. תגובות הביניים האלה מעובדות פנימית — הדפדפן פועל עליהן (מתחיל לטעון משאבים שנרמזו, ממתין לפני שליחת הגוף, משדרג את הפרוטוקול) אבל חושף לקוד שלך רק את התגובה הסופית.

האם אני צריך לממש טיפול ב-100 Continue בשרת שלי?

רוב ה-frameworks מטפלות בזה אוטומטית. אם אתה בונה שרת מאפס שמקבל העלאות גדולות, עליך לבדוק את הכותרת Expect: 100-continue ולהגיב בהתאם לפני קריאת גוף הבקשה. אבל frameworks כמו Express, Django ו-Rails מטפלות בזה עבורך.

האם אני יכול לשלוח מספר תגובות 1xx לפני התגובה הסופית?

כן. שרת יכול תיאורטית לשלוח 103 Early Hints, לאחר מכן 100 Continue, ולאחר מכן את 200 OK הסופי. בפועל, לעיתים נדירות תראה יותר מתגובת ביניים אחת לכל בקשה.

Esta página foi útil?

😔
🤨
😃