როგორ ამუშავებს გადამისამართებადი პროქსი მორგებულ API სათაურს
თვალი ადევნეთ API-ის ვერსიის ველს ჩვეულებრივი გადაცემის, ჰოპისთვის დამახასიათებელი Connection წესებისა და ცალსახად კონფიგურირებული სათაურების პოლიტიკის გავლით.
API-ს შეუძლია თავისი ვერსია ატაროს მორგებულ მოთხოვნის ველში, მაგალითად API-Version. ჩვეულებრივმა გადამისამართებადმა პროქსიმ არ უნდა გადააგდოს ეს ველი მხოლოდ იმიტომ, რომ სახელი უცნობია. HTTP მოითხოვს უცნობი ველების გადაცემას, თუ არ მოქმედებს განსაზღვრული გამონაკლისი ან კონფიგურირებული პოლიტიკა.
ველი Connection სწორედ ერთი ასეთი გამონაკლისია. შეადარეთ ეს საილუსტრაციო მოთხოვნები:
API-Version: 2026-10
Connection: keep-aliveაქ API-ის ველი არ არის მონიშნული როგორც ლოკალური ამ კავშირისთვის. შემდეგ მაგალითში გამგზავნი ცალსახად ცვლის მის ფარგლებს:
API-Version: 2026-10
Connection: API-Versionგადამისამართებადი პროქსი გადაცემამდე შლის Connection-ის მიერ დასახელებულ ველებს და თავად კავშირზე სპეციფიკურ ინსტრუქციებსაც შლის ან ცვლის. ამიტომ წყაროსთვის განკუთვნილი აპლიკაციის სათაური არ უნდა გამოჩნდეს იმ ტოკენების სიაში.
იპოვეთ წერტილი, სადაც ველი იცვლება
შეადარეთ კლიენტის მიერ აწყობილი მოთხოვნა, პროქსის მიერ მიღებული და გადაცემული ველები და ის, რაც წყარომ მიიღო. კლიენტს შეუძლია სათაური გამოტოვოს მანამ, სანამ პროქსი მას დაინახავს; კონფიგურირებულ ფილტრს შეუძლია განზრახ მოხსნას იგი; სერვერს შეუძლია მოთხოვნა უარყოს სათაურების ლიმიტის გადაჭარბების გამო.
ნუ გამოიტანთ დასკვნას ჩუმად მოხსნაზე მხოლოდ ძველ განლაგებაში მოხსენებული სათაურის ზომის ზღვრიდან. ლიმიტები და უარყოფის ქცევა ეკუთვნის ფაქტობრივ კომპონენტებსა და კონფიგურაციას. შეინახეთ HTTP პასუხი და შესაბამისი ჟურნალები დაკვირვებასთან ერთად.
ჩვეულებრივი CONNECT გვირაბის შიგნით ბოლოდან ბოლომდე HTTPS-ის შემთხვევაში პროქსი ვერ წაიკითხავს და შერჩევით ვერ მოხსნის შიდა API ველს. მაშინ სათაურების შემოწმება ეკუთვნის TLS-ის ბოლოებს ან ცალსახად სანდო შემოწმების შუამავალს.