Hypertext Transfer Protocol

Hypertext Transfer Protocol (ראשי תיבות: HTTP) הוא פרוטוקול תקשורת שנועד להעברת דפי HTML ואובייקטים שהם מכילים (כמו תמונות, קובצי קול, סרטוני פלאש וכו') ברשת האינטרנט וברשתות אינטראנט. הפרוטוקול פועל בשכבת היישום של מודל ה-OSI ובשכבת היישום של מודל TCP/IP. שרתי HTTP הם שרתי התוכן המרכזיים ברשת האינטרנט ודפדפנים הם תוכנות הלקוח הנפוצות ביותר לפרוטוקול HTTP.

התקשורת בין השרת ללקוח ב-HTTP נעשית באמצעות בקשות ששולח הלקוח ותשובות שמחזיר השרת. ראשית, הלקוח יוצר חיבור לכתובת ה-IP ולפורט שבו השרת נמצא, בדרך כלל פורט 80. לאחר מכן נשלחת הבקשה, הכוללת את הכתובת של האובייקט המבוקש (למשל, דף HTML) ופרטים נוספים על הבקשה ועל הלקוח. השרת קורא את הבקשה, מפענח אותה, שולח ללקוח תשובה בהתאם ולרוב מנתק את החיבור ללקוח כשהשליחה הסתיימה.

היסטוריה

הגרסה הראשונה של הפרוטוקול שהייתה בשימוש (0.9) הייתה פשוטה ביותר ולא תמכה ברוב האפשרויות הקיימות כיום. שיטת הבקשה היחידה בגרסה זו הייתה GET, לא הוגדרו שדות כותרת והבקשות לא כללו את גרסת ה-HTTP כפי שהן כיום. כתוצאה מכך הלקוח לא יכול היה להעביר לשרת שום אינפורמציה נוספת פרט לכתובת של העמוד המבוקש. התשובה של השרת הכילה את האובייקט שכתובתו ניתנה בבקשה, גם כן ללא שדות כותרת, ואינדיקציה לסוף ההודעה ניתנה על ידי ניתוק חיבור ה-TCP על ידי השרת. מכיוון שהתשובות הכילו רק את האובייקט המבוקש, הודעות שגיאה נשלחו גם הן בפורמט HTML ולא היה ניתן להבחין ביניהן לבין דפים רגילים.

במאי 1996 התפרסמה גרסה 1.0 של הפרוטוקול, שנמצאת עדיין בשימוש נרחב בעיקר על ידי שרתי פרוקסי. בגרסה זו נוספו שיטות הבקשה HEAD, POST, PUT, DELETE, LINK ו-UNLINK ובקשות נדרשו לציין את גרסת הפרוטוקול. תשובות השרת כללו עתה פרט לתוכן הדף המבוקש, קוד מיוחד שמציין את תוצאת הבקשה (ראו להלן), מלווה בהסבר טקסטואלי בן מספר מילים על משמעות הקוד. הוגדרו כ-30 שדות כותרת, שנועדו בין השאר לייעל את השימוש במטמון, לציין מראש את אורך ההודעה, לאפשר הפניות אוטומטיות בין דפים ולהעביר מידע נוסף.

הגרסה הנוכחית, 1.1, פורסמה ביוני 1999 והתבססה ברובה על גרסה 1.0. ההבדלים העיקריים בין גרסה זו לקודמתה הם שליטה טובה יותר במטמון, הוספת שיטות הבקשה OPTIONS ו-TRACE, תמיכה ב-multiple hosts ותוספות מתקדמות שמטרתן לייעל את אופן הפעולה של הפרוטוקול. כמו כן, הוסרו מספר אפשרויות שהיו קיימות בגרסה הקודמת, לרוב משום שנמצאו לא שימושיות. מאפיין חשוב שנתמך בגרסה זו הוא האפשרות להשתמש בחיבור יחיד עבור מספר בקשות, במקום לפתוח חיבור חדש עבור כל אובייקט שנמצא בדף שהתקבל בתשובה הראשונה.

נעשו נסיונות להרחיב את הפרוטוקול וליצור גרסה 1.2, אך הם לא יצאו לפועל.

בקשות HTTP

בקשות HTTP מורכבות מהנתונים הבאים:

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

שיטות בקשה

נכון לגרסה 1.1, קיימות 8 שיטות בקשה: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE ו-CONNECT. ניתן לסווג אותן בשני אופנים: שיטות בטוחות לעומת שיטות לא בטוחות, ושיטות אידמפוטנטיות (idempotent) לעומת שיטות שאינן אידמפוטנטיות. סיווגים אלו נועדו להוות אינדקציה כללית עבור שרתים, דפדפנים ובוני אתרים באשר למידת ההשפעה של כל אחת מהשיטות על השרת ועל הלקוח.

שיטות בטוחות מוגדרות ככאלה שמיועדות רק לשם קבלת מידע מהשרת; הן לא אמורות לשמש, למשל, לשליחת מידע מהלקוח לשרת, לביצוע שינויים כלשהם במסדי נתונים שנמצאים על השרת וכו'. במילים אחרות, אין לשיטות אלה "תופעות לוואי" פרט לקבלת מידע. GET ו-HEAD נחשבות לשיטות בטוחות.

שיטות אידמפוטנטיות הן שיטות ששליחה חוזרת שלהן גורמת לאותן תופעות לוואי כמו שליחה אחת. שיטות שהן בטוחות הן, לפי ההגדרה, גם אידמפוטנטיות, משום שאין להן כלל תופעות לוואי. השיטות PUT ו-DELETE גם הן נכללות בסיווג זה.

אלו הן שיטות הבקשה הנתמכות בגרסה 1.1:

GET

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

HEAD

מבקשת מהשרת לשלוח את כל שדות הכותרת שהיו נשלחים לבקשת GET, אך בלי האובייקט עצמו. השיטה נועדה, בין השאר, לאפשר בדיקה של קישורים שבורים או זמני שינויים של אובייקטים מבלי לבקש את כל האובייקט.

POST

בקשות המכילות גוף הודעה. בקשות POST משמשות בדרך כלל לשליחה של נתונים מטפסי HTML לשרת לשם עיבוד.

PUT

מבקשת מהשרת לשמור את גוף ההודעה המצורף לבקשה בתור אובייקט, שכתובתו היא הכתובת שניתנה בתחילת הבקשה.

DELETE

מבקשת מהשרת למחוק את האובייקט שכתובתו מצוינת בתחילת הבקשה.

OPTIONS

מבקשת מהשרת מידע על דרכי התקשורת האפשריות ביחס לאובייקט מסוים או ביחס לשרת עצמו.

TRACE

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

CONNECT

הפרוטוקול אינו מגדיר את השימוש ב-CONNECT, אך שומר את השיטה הזו לשימוש עבור שרתי פרוקסי שמסוגלים להתנהג כמו תעלות SSL.

כתובות בבקשות HTTP

כתובת בבקשת HTTP יכולה להיות כתובת מלאה (כמו: http://www.w3.org/Protocols) או כתובת יחסית לשרת (כמו: Protocols/). השימוש בכתובות יחסיות הוא הנפוץ ביותר, דבר שהקשה בעבר על אחסון של מספר אתרים על אותו שרת, משום שהשרת לא יכול היה לדעת לאיזה אתר מבין האתרים המאוחסנים אצלו מכוונת הבקשה. כדי לפתור את הבעיה מבלי לאבד את התמיכה לאחור בגרסאות קודמות, גרסה 1.1 מחייבת כל בקשה לכלול שדה כותרת בשם host, שערכו הוא שם התחום של האתר אליו מיועדת הבקשה.

תשובות HTTP

לאחר קריאת הבקשה ששלח הלקוח, השרת מחזיר תשובה שמכילה:

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

קוד המצב ומשמעותו

ערך מורחב – שגיאות של HTTP

כאמור, קוד המצב מורכב ממספר תלת ספרתי והסבר קצר (בן שורה אחת) על משמעות הקוד. המספרים מחולקים ל-5 מחלקות, בהתאם לספרה הראשונה שלהם:

1xx - ההודעה מכילה מידע אינפורמטיבי בלבד.
2xx - הבקשה ששלח הלקוח בוצעה בהצלחה על ידי השרת, והתשובה מכילה את מה שהשרת נתבקש לשלוח בהתאם לשיטת הבקשה.
3xx - הבקשה פוענחה בהצלחה, אך מסיבות כלשהן התשובה אינה כוללת את האובייקט המבוקש (למשל, משום שהעמוד מפנה אוטומטית לעמוד אחר).
4xx - נמצאה שגיאה כלשהי בבקשה עצמה.
5xx - השרת לא הצליח למלא אחר הבקשה כתוצאה מכשל פנימי.

אם לקוח מקבל תשובה מהשרת שמכילה קוד שלא מוכר לו, הפרוטוקול מציע ללקוח לשייך את הקוד לאחת המחלקות הנ"ל לפי הספרה הראשונה ולפעול כאילו שתי הספרות הנותרות היו 00. כך מתאפשרת הרחבה של הפרוטוקול תוך שמירה על תמיכה לאחור.

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

להלן כמה ממספרי המצב הנפוצים ברשת האינטרנט:

100 (Continue)

קוד זה נשלח לאחר שהשרת קיבל את החלק הראשוני של הבקשה מהלקוח, והוא נועד ליידע את הלקוח שהשרת מוכן לקבל את המשך ההודעה. קוד 100 משמש בעיקר במצב של חיבור קבוע שדרכו עוברות מספר בקשות.

200 (OK)

זהו קוד המצב הנפוץ ביותר, והוא מציין שהבקשה עובדה בהצלחה על ידי השרת. התוכן של שאר ההודעה תלוי בשיטת הבקשה ששלח הלקוח: בתשובה לבקשות GET השרת ישלח את האובייקט שצויין בבקשה, בתשובה לבקשות HEAD יישלחו שדות הכותרת וכו'.

204 (No Content)

השרת עיבד את הבקשה ושלח תגובה, אך מסיבה כלשהי תשובת השרת אינה מכילה גוף וכוללת רק שדות כותרת.

206 (Partial Content)

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

300 (Multiple Choices)

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

301 (Moved Permanently)

הכתובת שצויינה בבקשה מיושנת, והאובייקט שאליו היא התייחסה בעבר נמצא כעת תחת כתובת חדשה, המצורפת לתשובת השרת. אם שיטת הבקשה היא GET או HEAD, הלקוח בדרך כלל מפנה את הבקשה באופן אוטומטי לכתובת החדשה, וזיכרון המטמון מתעדכן בהתאם.

302 (Found)

זהה ל-301, פרט לכך שהאובייקט נמצא בכתובת החדשה באופן זמני בלבד. גם כאן, אם שיטת הבקשה הייתה GET או HEAD, הלקוח בדרך כלל מפנה באופן אוטומטי לכתובת המצורפת לתשובת השרת.

304 (Not Modified)

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

400 (Bad Request)

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

401 (Unauthorized)

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

403 (Forbidden)

האובייקט המבוקש נמצא על השרת, אך אינו מיועד לשליחה. למשל, אתרים רבים לא מאפשרים למשתמשים חיצוניים לראות את תוכן התיקיות באתר שלהם, ומשתמשים בקוד הזה כדי לציין זאת כאשר הכתובת בבקשה מתייחסת לתיקייה ולא לקובץ ספציפי. לעתים שרתים שולחים קוד מצב 404 במקום 403, כדי להסוות את עצם קיומו של האובייקט.

404 (Not Found)

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

500 (Internal Server Error)

השרת לא הצליח למלא אחר הבקשה כתוצאה מכשל פנימי כלשהו.

501 (Not Implemented)

השרת לא מסוגל למלא אחר הבקשה מסיבה כלשהי, לרוב משום שהוא לא תומך בשיטת הבקשה שביקש הלקוח.

503 (Service Unavailable)

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

504 (Gateway Timeout)

אחד משרתי הפרוקסי או המעברים (gateways) הנמצאים בין הלקוח לשרת העבירו את הבקשה לתחנה הבאה אחריהם, אבל לא קיבלו ממנה תשובה בפרק זמן סביר, ונקבע timeout.

שדות כותרת

הגרסה הנוכחית של HTTP תומכת ב-47 שדות כותרת, נוסף על מספר הרחבות שהתווספו עם הזמן (כגון תמיכה בCookies). רבים מהם מבוססים על פרוטוקול MIME המשמש לשליחת הודעות בדואר אלקטרוני. כמעט כל השדות הם אופציונליים, פרט ל-host עבור בקשות, ושדות מסוימים המציינים את אורך גוף ההודעה עבור הודעות שבהן הוא לא ריק. עם זאת, מספר שרתים (כגון זה של ויקיפדיה העברית) מחייבים שימוש בשדות שאינם חובה בדרך כלל.

persistent connections

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

גרסה 1.1 שיפרה את המנגנון כך שיהיה ניתן להשתמש בו גם עם שרתי פרוקסי. המנגנון נוצר כך שיתאם גם למנגנון הקודם וגם לשרתים ישנים יותר. בנוסף, תוארו מספר מנגנונים ומוסכמות לשימוש יעיל ב-persistent connections, הוגדר אופן הטיפול בבעיות שעלולות להיווצר באחת או יותר מהבקשות והוקדש קוד מצב מיוחד (שמספרו 100) לניצול נוסף של המנגנון.

מטמון

השליטה במטמון ב-HTTP נעשית בשני אופנים, הנקראים "מנגנון האימות" ו"מנגנון התפוגה". מנגנון האימות מבוסס על פריט מידע שמוצמד לכל עמוד ונשלח יחד איתו. פריט המידע הזה יכול להיות התאריך האחרון בו שונה העמוד או מספר זיהוי הקרוי Entity tag המשתנה בכל פעם שתוכן העמוד משתנה. כשלקוח או שרת מטמון שולחים בקשה לעמוד מסוים שיש בידם עותק שלו שהתקבל מבקשה קודמת, הם מצרפים לבקשה את אחד מהנתונים האלו שנשלח בפעם האחרונה שהעמוד התקבל. לפי הנתון הזה, השרת יכול לדעת אם העותק עדכני, ואם לא - לשלוח את העמוד המעודכן במלואו, כפי שהיה שולח בתגובה לבקשה רגילה (כולל הנתונים החדשים שמצורפים אליו). אם העמוד לא השתנה, השרת שולח תשובה קצרה ללא גוף, שקוד המצב שלה הוא 304 (Not Modified), ובכך חוסך את שליחת העמוד כולו.

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

מנגנונים אלה פועלים בעזרת מספר שדות כותרת מיוחדים, ובעיקר בעזרת השדה Cache-Control המשמש הן לקוחות והן שרתים לשליטה באופן שבו הצד השני יטפל במטמון. בעזרתו, לקוח יכול להורות לשרת מטמון שעשוי להימצא בינו לבין השרת המקורי לאמת את העמוד שהוא מבקש אפילו אם נמצא אצלו עותק תקף של אותו עמוד, או לחלופין לשלוח לו את העמוד רק אם הוא נמצא אצלו בזיכרון מבלי לתקשר עם השרת. שרתים יכולים להורות ללקוח או לשרתי מטמון לא לשמור את העמוד שהם שולחים, לשמור אותו רק בתנאים מסוימים וכו'. שדות כותרת נוספים משמשים להצמדת נתונים רלוונטיים לעמודים שהשרת שולח או לבקשות אימות של עמודים שנמצאים בזיכרון מטמון.

ראו גם

• שרת HTTP

קישורים חיצוניים

מפרטים טכניים

• גרסה 0.9
• RFC 1945 - גרסה 1.0
• RFC 2616 - גרסה 1.1