პროქსიზებულ GET-ს შეუძლია სერვერამდე მიაღწიოს და შემდეგ გადამისამართებებს მიჰყვეს, სანამ საბოლოო წარუმატებლობა დაფარავს პირველ პასუხს. გამოავლინეთ ეს საწყისი პასუხი დიაგნოსტიკისთვის:

request = scrapy.Request(
    'https://service.example/page',
    callback=inspect_redirect,
    meta={
        'proxy': 'http://proxy.example:8080',
        'dont_redirect': True,
        'handle_httpstatus_list': [301, 302, 303, 307, 308],
    },
)

დაგეგმეთ ეს მოთხოვნა ობობას არსებული start ან callback ნაკადით. დაშვებული საჯარო გვერდის შემოწმებისთვის HTTP პროქსების სია გვთავაზობს კანდიდატებს მოთხოვნის პროქსი URL-ისთვის. inspect_redirect-მა უნდა ჩაიწეროს პასუხის სტატუსი და Location ჰედერი, ნაცვლად ბრმად ხელახლა მიყოლისა.

dont_redirect აჩერებს ავტომატურ გადამისამართებას ამ მოთხოვნისთვის. handle_httpstatus_list საშუალებას აძლევს დასახელებულ სტატუსებს callback-მდე მიაღწიონ, ნაცვლად იმისა, რომ HTTP შეცდომების ფილტრაციამ უარყოს ისინი. პარამეტრები middleware-ის სხვადასხვა პასუხისმგებლობას ეხება.

შეამოწმეთ, რას ირჩევს გადამისამართება: მოსალოდნელი კანონიკური URL, განსხვავებული სქემა ან ჰოსტის სახელი, შესვლის გვერდი ან განმეორებადი ციკლი. წარმატებული გადაცემის შემდეგ მიღებული 302 განსხვავებული დაკვირვებაა, ვიდრე პროქსი კავშირის გახსნის წარუმატებლობა.

როდესაც გადამისამართებების ჩვეულებრივი დამუშავება აღდგება, Scrapy პასუხის მოთხოვნის მეტამონაცემებში აჩვენებს redirect_urls-სა და redirect_reasons-ს. მათ შეუძლიათ შეინარჩუნონ საბოლოო შედეგამდე მიმავალი გზა, გადამისამართებები მთელი სკანირების განმავლობაში გამორთული რომ არ დარჩეს.

საბოლოო პასუხი ავტომატურად არ არის ის გვერდი, რომელიც აპლიკაციას ჰქონდა განზრახული. შეინახეთ დანიშნულება და პასუხის შიგთავსი მარშრუტიზაციის დიაგნოსტიკასთან ერთად.

დაკავშირებული სტატიები