1990: מהצעה לפרוטוקול עובד
במרץ 1989 הציע טים ברנרס-לי ב-CERN מערכת-היפרטקסט מבוזרת, אך זו נותרה בשלב-הצעה בלבד. רק מאוקטובר 1990, כשקיבל אישור לממש את הרעיון בפועל על מחשב מסוג NeXT, כתב בפועל את פרוטוקול HTTP לצד הדפדפן והשרת הראשונים; עד דצמבר 1990 היו הכלים האלה בשלים דיים כדי להעביר בהצלחה תקשורת בין לקוח-HTTP לשרת-HTTP — עדיין לפני שהמונח "רשת עולמית" נטבע רשמית לציבור הרחב. הגרסה המוקדמת הזו, שתועדה בדיעבד כ-HTTP/0.9, הייתה פשוטה עד קיצוניות: תמכה אך ורק בפקודת GET, החזירה מסמך HTML גולמי בלי כותרות (headers) כלל, וסגרה את החיבור מיד אחרי כל בקשה.
HTTP/1.0: כותרות, קודי-סטטוס וסוגי-תוכן (RFC 1945, 1996)
HTTP/1.0 תועד רשמית ב-RFC 1945 ב-1996, והוסיף לפרוטוקול הפשוט של HTTP/0.9 שלושה מרכיבים שחסרו לו: כותרות-בקשה ותגובה (headers), קודי-סטטוס (כמו 200 להצלחה או 404 לדף-שלא-נמצא), ותמיכה בסוגי-תוכן שונים מעבר ל-HTML הגולמי בלבד.
HTTP/1.1 והדרך אל תקן-הסמנטיקה המאוחד (1997–2022)
HTTP/1.1, שהתקבע ב-1997 ותוקן מחדש ב-RFC 2616 ב-1999, הוסיף חיבורים מתמשכים (persistent connections) שחוסכים בפתיחת-חיבור-חדש לכל בקשה — שיפור ביצועים דרמטי ביחס לגרסה הקודמת, והתקן שרוב הרשת עדיין נסמכת עליו במידה כלשהי גם היום. ב-2022 פרסם ה-IETF מחדש את סמנטיקת ה-HTTP המשותפת לכל הגרסאות כתקן-אינטרנט רשמי (RFC 9110, STD 97), שמבטל ומאחד סדרה ארוכה של RFCs קודמים — הפרדה מכוונת שמאפשרת לסמנטיקת-הפרוטוקול (שיטות, קודי-סטטוס, כותרות) להתפתח בנפרד מתחביר-ההעברה הספציפי של כל גרסה.
שיטות (Methods): GET, POST ומה זה בכלל "בטוח"
התקן המאוחד מגדיר את שיטות-הבקשה הסטנדרטיות של HTTP: GET לשליפת ייצוג של משאב, HEAD זהה ל-GET אך בלי גוף-תוכן, POST לעיבוד נתונים לפי סמנטיקת-המשאב (כמו שליחת טופס), PUT להחלפת מצב המשאב במלואו, DELETE למחיקתו, ועוד. ה-RFC מבחין בין שיטות "בטוחות" (safe) — כמו GET ו-HEAD — שלקוח יכול לצפות שלא יגרמו לתופעות-לוואי בצד השרת, ובין שיטות "אידמפוטנטיות" (idempotent) — כמו PUT ו-DELETE — שאפשר לחזור עליהן כמה פעמים ולקבל תמיד את אותה תוצאה. POST, לעומת זאת, אינה בטוחה ואינה אידמפוטנטית: שליחה כפולה של אותו טופס עלולה, למשל, ליצור שתי הזמנות זהות במקום אחת.
HTTP/2 (2015): ריבוב ודחיסת-כותרות, אבל לא פתרון מלא
HTTP/2, שהתבסס על פרוטוקול SPDY שפיתחה גוגל, אושר כתקן ב-2015 (ותועד מחדש ב-RFC 9113 ב-2022) והוסיף שני שיפורים מרכזיים: ריבוב (multiplexing) — היכולת לשלוח כמה בקשות ותגובות במקביל, כ"זרמים" (streams) נפרדים, על חיבור-TCP יחיד; ודחיסת-כותרות (HPACK), שמצמצמת משמעותית את גודל הבקשות בכתובות חוזרות. עם זאת, ה-RFC עצמו מציין במפורש מגבלה שנותרה: חסימת-ראש-התור (head-of-line blocking) של TCP אינה נפתרת בפרוטוקול הזה — כלומר חבילת-רשת בודדת שאבדה עדיין עוצרת את כל הבקשות שממתינות על אותו חיבור, גם אם הן לא קשורות אליה.
HTTP/3 (2022): QUIC מעל UDP פותר את חסימת-הראש
HTTP/3, שאושר ב-RFC 9114 ב-2022, זנח לחלוטין את שכבת ה-TCP המסורתית לטובת פרוטוקול QUIC מבוסס-UDP — כדי לפתור בדיוק את הבעיה שנותרה פתוחה ב-HTTP/2. לפי ה-RFC, ב-HTTP/2 מעל TCP חבילה שאבדה או הגיעה שלא-בסדר גורמת לכל הבקשות הפעילות להיתקע, גם אם רק אחת מהן נפגעה בפועל; QUIC, לעומת זאת, משלב ריבוב-זרמים ובקרת-זרימה לכל זרם, ומספק אמינות ברמת-הזרם הבודד לצד בקרת-עומס על פני החיבור כולו — כך שכשחבילה אובדת, רק הזרם הספציפי שנפגע נעצר, ולא כל שאר הבקשות על אותו חיבור. נכון לספטמבר 2026, לפי מדד W3Techs, כ-40.3% מהאתרים ברשת פועלים עם HTTP/3, וכ-34.6% עם HTTP/2.
חסר-מצב, בקשה-תגובה, ופורטים 80/443
מבחינה עקרונית HTTP הוא פרוטוקול "בקשה-תגובה" (request-response) "חסר-מצב" (stateless): כל בקשה נשלחת ונענית בנפרד, בלי שהשרת "זוכר" בקשות קודמות מאותו לקוח — עוגיות (cookies) הן פתרון-מאוחר שנוסף כדי לפצות על כך. הפרוטוקול פועל כברירת-מחדל דרך פורט 80 (לא-מוצפן) או פורט 443 (מוצפן, HTTPS). לפי מדד W3Techs מספטמבר 2026, כ-90.0% מהאתרים ברשת מגדירים כיום HTTPS כפרוטוקול ברירת-המחדל שלהם.