שיטת HTTP HEAD

GET אומר "שלח לי את זה." HEAD אומר "תאר לי את זה."

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

מה HEAD עושה

בקשת GET:

GET /large-video.mp4 HTTP/1.1
Host: example.com
→
HTTP/1.1 200 OK
Content-Type: video/mp4
Content-Length: 524288000
Last-Modified: Wed, 15 May 2024 10:00:00 GMT

[524 מגהבייט של נתוני וידאו]

בקשת HEAD:

HEAD /large-video.mp4 HTTP/1.1
Host: example.com
→
HTTP/1.1 200 OK
Content-Type: video/mp4
Content-Length: 524288000
Last-Modified: Wed, 15 May 2024 10:00:00 GMT

[ללא גוף]

אתה לומד שהקובץ הוא 524 מגהבייט, שהוא MP4, ומתי הוא שונה לאחרונה — מבלי להוריד אפילו בייט אחד של וידאו.

מתי להשתמש ב-HEAD

HEAD מתאים במיוחד כאשר אתה צריך לדעת על משאבים מבלי לאחזר אותם:

בדיקה אם משאבים קיימים:

HEAD /api/users/johndoe HTTP/1.1
→ 200 OK (המשתמש קיים)
→ 404 Not Found (המשתמש לא קיים)

בדיקת קישורים: סורקי אינטרנט ובודקי קישורים מאמתים קישורים מבלי להוריד דפים:

async function checkLink(url) {
  const response = await fetch(url, { method: 'HEAD' });
  return response.ok;
}

בדיקת גדלי קבצים לפני הורדה:

HEAD /downloads/large-file.zip
→ Content-Length: 1073741824

// 1 גיגהבייט — שאל את המשתמש לפני ההורדה

אימות רעננות משאב:

HEAD /data/report.pdf
→ Last-Modified: Wed, 15 May 2024 10:00:00 GMT
→ ETag: "abc123"

// השווה עם הגרסה שנשמרה במטמון

קביעת סוגי תוכן:

HEAD /file-without-extension
→ Content-Type: application/pdf

// עכשיו אנחנו יודעים שזה PDF

HEAD ומטמון

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

זה הופך את HEAD לשימושי לאימות מטמון:

HEAD /api/data HTTP/1.1
If-Modified-Since: Wed, 15 May 2024 10:00:00 GMT
→
HTTP/1.1 304 Not Modified

// המטמון עדיין עדכני, אין צורך בהורדה

דרישות יישום

RFC 9110¹ מציין שהשרתים צריכים לשלוח את אותן כותרות בתגובה ל-HEAD כפי שהיו שולחים ל-GET. המפרט משתמש ב-"should" ולא ב-"must" מכיוון שכותרות מסוימות ניתן לקבוע רק בזמן יצירת התוכן — ויצירת תוכן מלא רק כדי להשליך אותו מסכלת את מטרתו של HEAD.

כלומר, טיפול HEAD שממומש היטב:

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

מימוש יעיל:

app.head('/articles/:id', (req, res) => {
  const metadata = getArticleMetadata(req.params.id);

  if (!metadata) {
    return res.status(404).end();
  }

  res.set('Content-Length', metadata.size);
  res.set('Content-Type', 'text/html');
  res.set('Last-Modified', metadata.modified);
  res.set('ETag', metadata.etag);
  res.status(200).end();
});

אחזר רק מטה-נתונים — אל תייצר תוכן מלא רק כדי להשליך אותו.

HEAD לעומת GET לבדיקת קיום

יתרונות HEAD:

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

יתרונות GET:

• כנראה תצטרך את התוכן ממילא
• בקשה אחת במקום HEAD ואז GET
• חלק מהשרתים לא תומכים ב-HEAD כראוי

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

// בדוק אם קובץ גדול קיים לפני הורדה
const headResponse = await fetch(url, { method: 'HEAD' });

if (headResponse.ok) {
  const size = headResponse.headers.get('Content-Length');

  if (confirm(`הורד ${formatBytes(size)}?`)) {
    const getResponse = await fetch(url);
    // הורד קובץ
  }
}

שיקולי אבטחה

בקשות HEAD יכולות לדלוף מידע. החל את אותן הגנות כמו GET:

נדרש אימות זהות: HEAD צריך לאכוף את אותו אימות זהות והרשאה כמו GET:

HEAD /users/123/private-data
→ 401 Unauthorized (אם לא מאומת)
→ 403 Forbidden (אם מאומת אך לא מורשה)

חשיפת מידע: כותרות יכולות לחשוף מידע רגיש:

HEAD /internal-document.pdf
→ Last-Modified: מראה מתי המסמך עודכן
→ Content-Length: מראה את גודל המסמך
→ X-Author: עלול לחשוף את שם המחבר

ודא שתגובות HEAD לא מדליפות מידע שגם GET לא היה חושף.

אי-עקביות בתמיכת שרתים

בעוד שהשרתים אמורים לתמוך ב-HEAD עבור כל נקודת קצה של GET, המציאות מסובכת יותר:

• חלק מהשרתים מחזירים 405 Method Not Allowed
• חלק מחזירים כותרות שונות ממה ש-GET היה מחזיר
• חלק מהמסגרות לא ממירות אוטומטית טיפולי GET ל-HEAD

פתרון עקיפה לצד הלקוח:

async function headRequest(url) {
  try {
    return await fetch(url, { method: 'HEAD' });
  } catch (error) {
    // עבור ל-GET אם HEAD נכשל
    return await fetch(url);
  }
}

HEAD ובקשות טווח

HEAD עובד עם כותרות Range לבדיקה אם שרת תומך בתוכן חלקי:

HEAD /large-file.zip HTTP/1.1
Range: bytes=0-0
→
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 1
Content-Range: bytes 0-0/1073741824

// השרת תומך בבקשות טווח, הגודל הכולל הוא 1 גיגהבייט

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

HEAD ב-APIs

ממשקי RESTful API צריכים לתמוך ב-HEAD עבור נקודות קצה של משאבים:

HEAD /api/v1/users/12345
→ 200 OK (המשתמש קיים)
→ 404 Not Found (המשתמש לא קיים)

HEAD /api/v1/articles/latest
→ Last-Modified: Wed, 15 May 2024 10:00:00 GMT
→ ETag: "abc123"

חלק מממשקי ה-API משתמשים ב-HEAD לבדיקות תקינות:

HEAD /health
→ 200 OK (השירות תקין)
→ 503 Service Unavailable (השירות לא זמין)

דפוסי ביצועים

GET מותנה: בדוק רעננות לפני הורדה:

const headResponse = await fetch(url, { method: 'HEAD' });
const etag = headResponse.headers.get('ETag');

if (etag === cachedETag) {
  return cachedContent;
}

const getResponse = await fetch(url);

בדיקת גודל מראש:

const head = await fetch(downloadUrl, { method: 'HEAD' });
const size = parseInt(head.headers.get('Content-Length'));

if (size > MAX_SIZE) {
  throw new Error('הקובץ גדול מדי');
}

בדיקת זמינות מחזורית:

async function waitForResource(url) {
  while (true) {
    const response = await fetch(url, { method: 'HEAD' });

    if (response.ok) {
      return true;
    }

    if (response.status === 404) {
      await sleep(1000);
      continue;
    }

    throw new Error(`סטטוס בלתי צפוי: ${response.status}`);
  }
}

שאלות נפוצות על שיטת HTTP HEAD

מדוע שרת לא יתמוך ב-HEAD אם הוא תומך ב-GET?

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

האם ניתן לשמור תגובות HEAD במטמון?

כן. תגובות HEAD עוקבות אחרי אותם כללי מטמון כמו GET. דפדפנים ושרתי פרוקסי שומרים תגובות HEAD במטמון ויכולים להחזיר אותן לבקשות HEAD עוקבות מבלי לפנות לשרת המקור. כותרות המטמון (Cache-Control, ETag, Last-Modified) פועלות באופן זהה.

האם HEAD מהיר יותר מ-GET?

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

האם כדאי להשתמש ב-HEAD לבדיקה אם נקודת קצה של API קיימת לפני קריאה אליה?

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

מקורות