הבעיה היא שדרך נטרפי השרת של ההורדה מ GITHUB מחזיר סטטוס 200 OK במקום סטטוס 206 Partial Content.

אם השרת מחזיר סטטוס 206 Partial Content: התוכנה מבינה שהשרת תומך בבקשת טווחים, מסמנת "אפשרות חידוש: כן" (Resume: Yes), ומפצלת את ההורדה למספר חיבורים מקבילים.
אם השרת מחזיר סטטוס 200 OK: התוכנה מבינה שהמידע מגיע כזרם אחוד מתחילתו ועד סופו בלבד. היא מסמנת "אפשרות חידוש: לא" (Resume: No), עוברת להוריד בחיבור יחיד בלבד, ולא תוכל לחדש את ההורדה במידה והחיבור יתנתק.

שאלתי כעת את גימני, איך זה קשור לנטפרי, הוא ענה לי:
למה זה קורה בנטפרי ובווליום גבוה דווקא בהורדות מ-GitHub?

סריקת קבצים ואינטרספציה של הפרוקסי:
קובצי התקנה (.exe) ב-GitHub מאוחסנים על שרתי הענן של AWS S3 (בכתובת objects.githubusercontent.com). כדי לבדוק ולסרוק קבצים אלו, מערכת הסינון של נטפרי מתווכת את התקשורת. במהלך הסריקה והעברת הנתונים בזרם רציף (Stream) שנבדק, שרת הסינון אינו מעביר את כותרת ה-Range של המשתמש אל השרת המקורי או מנטרל אותה בדרך חזרה, ומחזיר למחשב שלך סטטוס 200 OK סטנדרטי.

הסירבול מול מנגנון הקישורים של GitHub:
GitHub אינה מגישה את הקובץ מהכתובת המקורית שראית בדפדפן, אלא מפיקה הפניה (Redirect) לקישור זמני חתום שפג תוקפו תוך זמן קצר. כש-IDM מנסה לחדש הורדה, הוא מנסה להשתמש בקישור שפג תוקפו או לבקש Range מחדש, אך מכיוון שנטפרי מחזירה 200 OK, התוכנה נכשלת לחלוטין בהורדה ומציגה שאין אפשרות המשכה.

מכיוון שהחסימה ל-206 Partial Content מתרחשת ברמת שרת הסינון המתווך, אף תוכנה חיצונית (IDM, FDM או סקריפט PowerShell) לא תוכל להמשיך הורדה שנעצרה כל עוד התגובה המתקבלת היא 200 OK.

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

תמיכה ב-206 Partial Content ובכותרות Range היא רכיב בפרוטוקול העברת הנתונים (HTTP), ואינה סותרת את עצם הסינון או הבדיקה של הקובץ.
איך נטפרי יכולה לממש זאת טכנית מבלי לפגוע בסינון?

הפרדה בין אישור התוכן לאופן העברתו:
הסינון קובע האם מותר להוריד את הקובץ (בדיקת כתובת ה-URL, סריקת וירוסים או בדיקת קובץ). פרוטוקול ה-Range עוסק רק באיך המידע מועבר למחשב שלך (במקטעים מקבילים או בחידוש הורדה). ברגע שקובץ או קישור ב-GitHub הוגדר כמורשה, אין מניעה בטיחותית לאפשר ללקוח לבקש חלקים מסוימים ממנו.

ניהול טווחים ברמת שרת הפרוקסי (Proxy Range Handling):
שרת הסינון יכול לקבל את בקשת ה-Range מהלקוח (למשל: "תן לי את בייטים 100MB עד 150MB"), להעביר אותה כפי שהיא לשרתי AWS/GitHub, ולהחזיר ללקוח תשובת 206 Partial Content תקנית. לחלופין, שרת הסינון יכול לאגור (Cache) את הקובץ המאושר אצלו ולספק ממנו מקטעים לפי דרישה.

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

למה הבעיה קיימת כיום?

הסיבה לכך כיום אינה רצון "להחמיר" בסינון, אלא מגבלה ארכיטקטונית של רכיב ה-Proxy (שרת התיווך): כאשר הפרוקסי מיירט ומעביר תעבורת HTTPS שנבדקת, קל ופשוט יותר תכנתית לטפל בה כזרם רציף יחיד (Stream) מאשר לנהל מנגנון מורכב של בקשות טווח מקבילות ורענון טוקנים זמניים של GitHub.
מה מומלץ לעשות?

מכיוון שאין כאן התנגשות עם ערכי הסינון, פנייה מסודרת לתמיכה של נטפרי (בצירוף הקלטת תעבורה בזמן הורדה ב-IDM או בסקריפט) תוכל להביא את הנושא לפיתוח. הגדרת הבקשה כ"תמיכה ב-HTTP Range / 206 עבור הורדות מורשות מ-GitHub" תבהיר לצוות הפיתוח שלהם מדובר בשיפור תשתיתי שאינו משפיע על ניטור התוכן.
עד כאן התשובה של גימני.