Hypertext Transfer Protocol

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

התקשורת ב־HTTP מתחילה ביצירת שיחה בין השרת ללקוח באמצעות פרוטוקול TCP או UDP בגרסה 3 של הפרוטוקול, ונמשכת בסדרה של בקשות (requests) ותשובות (responses) שנשלחות על ידי הלקוח והשרת, בהתאמה. ראשית, הלקוח יוצר חיבור לכתובת ה-IP ולפורט שבו השרת נמצא, בדרך כלל פורט 80 או 443. לאחר מכן נשלחת הבקשה, הכוללת את הכתובת של האובייקט המבוקש (למשל, דף HTML) ופרטים נוספים על הבקשה ועל הלקוח. השרת קורא את הבקשה, מפענח אותה, שולח ללקוח תשובה בהתאם ומנתק את החיבור ללקוח כשהשליחה הסתיימה, או משאיר אותו פתוח לבקשות נוספות.

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

בשנת 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, ותוספות מתקדמות שמטרתן לייעל את אופן הפעולה של הפרוטוקול. כמו כן, הוסרו מספר אפשרויות שהיו קיימות בגרסה הקודמת, לרוב משום שנמצאו לא שימושיות. מאפיין חשוב שנתמך בגרסה זו הוא האפשרות להשתמש בחיבור יחיד עבור מספר בקשות, במקום לפתוח חיבור חדש עבור כל אובייקט שנמצא בדף שהתקבל בתשובה הראשונה.

ב-2015, 15 שנה אחרי הגרסה האחרונה של HTTP, יצאה גרסה HTTP/2 (במקור HTTP/2.0) של הפרוטוקול. הגרסה שמרה על הסמנטיקות של הפרוטוקול, כגון סוגי הבקשות והתשובות, אולם שינתה את המנגנון מתחת, לדוגמה, היא מאפשרת שליחת מספר בקשות במקביל באותו חיבור ודחיסה של שדות הכותרת.

ב-16 ביוני 2022 הIETF פרסם את גרסה HTTP/3 של הפרוטוקול, שמבוססת על QUIC, פרוטוקול ריבוי ערוצי תעבורה (multiplexed) שמבוסס על פרוטוקול UDP, במקום TCP שבו השתמשו הגרסאות הקודמות. הפרוטוקול שומר על הסמנטיקה של הגרסאות הקודמות, אולם הוא משנה את הדרך שבה המידע מועבר, וגורם לשיפור במהירות הטעינה, במיוחד למכשירים עם latency גבוה^[1]. הפרוטוקול מתוקנן על ידי RFC 9114^[2].

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

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

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

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

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

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

GET (קבל)

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

HEAD (כותרת)

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

POST (שלח)

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

PUT (שים)

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

DELETE (מחק)

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

OPTIONS (אפשרויות)

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

לדוגמה: קריאה ל-OPTIONS יכולה להגיע עם תשובה מהשרת שהוא מקבל GET, Post, PUT, Head ו-OPTIONS. אבל לא מקבל DELETE ו-TRACE.

TRACE (שחזר)

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

CONNECT (התחבר)

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

PATCH (תיקון)

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

כל שרתי ה- HTTP הכלליים נדרשים ליישם לפחות את שיטות ה-GET וה-HEAD. כל שיטה אחרת נחשבת אופציונלית.

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

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

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

ערך מורחב – קוד מצב של 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, הלקוח בדרך כלל מפנה באופן אוטומטי לכתובת המצורפת לתשובת השרת.

303 (See Other)

הפניית יישום רשת לכתובת URI חדשה.

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.

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

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

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

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

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

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

הדוגמאות הבאות התקבלו בעזרת לקוח טלנט של יוניקס^[4], עם

telnet www.google.com 80 

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

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

GET / 

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

HTTP/1.0 302 Found Cache-Control: private Content-Type: text/html; charset=UTF-8 Location: http://www.google.co.il/?gfe_rd=cr&i=LhIOWOfFM6Hz8wfj_ICADQ Content-Length: 261 Date: Mon, 24 Oct 2016 13:52:46 GMT  <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>302 Moved</TITLE></HEAD><BODY> <H1>302 Moved</H1> The document has moved <A HREF="http://www.google.co.il/?gfe_rd=cr&amp;ei=lCYOWIy6EKvz8wfG_YCQBA">here</A>. </BODY></HTML> 

Connection closed by foreign host.

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

GET / HTTP/1.1 host: www.google.com בסוף הכותרת נדרשת שורה ריקה 

HTTP/1.1 302 Found Cache-Control: private Content-Type: text/html; charset=UTF-8 Location: http://www.google.co.il/?gfe_rd=cr&ei=-DYOWN3AIcqC8QeS9ID4Cw Content-Length: 261 Date: Mon, 24 Oct 2016 16:29:44 GMT  <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>302 Moved</TITLE></HEAD><BODY> <H1>302 Moved</H1> The document has moved <A HREF="http://www.google.co.il/?gfe_rd=cr&amp;ei=-DYOWN3AIcqC8QeS9ID4Cw">here</A>. </BODY></HTML> 

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

• שרת HTTP
• HTTP Secure
• Session
• Referer
• אל תעקוב (DNT, Do Not Track)

מדיה וקבצים בנושא Hypertext Transfer Protocol בוויקישיתוף

• אתר האינטרנט הרשמי של Hypertext Transfer Protocol (באנגלית)
• David Gourley, Brian Totty, Marjorie Sayer, Anshu Aggarwal, Sailu Reddy, HTTP: The Definitive Guide, ‏ספטמבר 2002 (באנגלית)
• פרוטוקול HTTP – מדריך למתחילים, באתר I, Code
• Hypertext Transfer Protocol, באתר אנציקלופדיה בריטניקה (באנגלית)

• גרסה 0.9
• RFC 1945, (על פי הקיצור, RFC הוא רק בקשה לתגובות) – גרסה 1.0
• RFC 2616 – גרסה 1.1