Hypertext Transfer Protocol

היסטוריה

ב-1991 פורסמה הגרסה הראשונה של הפרוטוקול שהייתה בשימוש (0.9). גרסה זו הייתה פשוטה ביותר ולא תמכה ברוב האפשרויות הקיימות כיום. שיטת הבקשה היחידה בגרסה זו הייתה GET, לא הוגדרו שדות כותרת והבקשות לא כללו את גרסת ה-HTTP כפי שהן כיום. כתוצאה מכך הלקוח לא יכול היה להעביר לשרת שום אינפורמציה נוספת פרט לכתובת של העמוד המבוקש. התשובה של השרת הכילה את האובייקט שכתובתו ניתנה בבקשה, גם כן ללא שדות כותרת, ואינדיקציה לסוף ההודעה ניתנה על ידי ניתוק חיבור ה-TCP על ידי השרת. מכיוון שהתשובות הכילו רק את האובייקט המבוקש, הודעות שגיאה נשלחו גם הן בפורמט HTML ולא היה ניתן להבחין ביניהן לבין דפים רגילים.
במאי 1996 התפרסמה גרסה 1.0 של הפרוטוקול, שנמצאת עדיין (אוקטובר 2007) בשימוש נרחב בעיקר על ידי שרתי פרוקסי. בגרסה זו נוספו שיטות הבקשה HEAD, POST, PUT, DELETE, LINK ו-UNLINK ובקשות נדרשו לציין את גרסת הפרוטוקול. תשובות השרת כללו עתה פרט לתוכן הדף המבוקש, קוד מיוחד שמציין את תוצאת הבקשה (ראו להלן), מלווה בהסבר טקסטואלי בן מספר מילים על משמעות הקוד. הוגדרו כ-30 שדות כותרת, שנועדו בין השאר לייעל את השימוש במטמון, לציין מראש את אורך ההודעה, לאפשר הפניות אוטומטיות בין דפים ולהעביר מידע נוסף.
הגרסה הנוכחית, HTTP/1.1, פורסמה ביוני 1999 והתבססה ברובה על גרסה 1.0. ההבדלים העיקריים בין גרסה זו לקודמתה הם שליטה טובה יותר במטמון, הוספת שיטות הבקשה OPTIONS ו-TRACE, תמיכה ב-virtual hosts, ותוספות מתקדמות שמטרתן לייעל את אופן הפעולה של הפרוטוקול. כמו כן, הוסרו מספר אפשרויות שהיו קיימות בגרסה הקודמת, לרוב משום שנמצאו לא שימושיות. מאפיין חשוב שנתמך בגרסה זו הוא האפשרות להשתמש בחיבור יחיד עבור מספר בקשות, במקום לפתוח חיבור חדש עבור כל אובייקט שנמצא בדף שהתקבל בתשובה הראשונה.
נעשו ניסיונות להרחיב את הפרוטוקול וליצור גרסה 1.2, אך הם לא יצאו לפועל.

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

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

שדות כותרת

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

persistent connections

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

מטמון

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

דוגמאות

הדוגמאות הבאות התקבלו בעזרת לקוח טלנט של יוניקס, עם
telnet www.google.com 80
80 הוא מספר הפורט בו השרת ממתין לפניות. telnet הוא שם התוכנית המפעילה לקוח טלנט במרבית מערכות ההפעלה. www.google.com הוא שם המתחם בו נמצא השרת. הוא יתורגם על ידי לקוח הטלנט לכתובת IP לפני שהלקוח יוכל לפנות לשרת.
מספור השורות להלן נועד לנוחות, ואינו חלק מהפרוטוקול. שורות ריקות המתחיבות על ידי הפרוטוקול מסומנות בצבע צהוב, וכיתוב בהן אינו חלק מהפרוטוקול.