Scrapy તેને અનુસરતા પહેલાં રીડાયરેક્ટ બતાવી શકે છે

પ્રોક્સી 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 નામ આપેલી સ્થિતિઓને HTTP-ભૂલ ફિલ્ટરિંગ દ્વારા નકારવાને બદલે callback સુધી પહોંચવા દે છે. આ સેટિંગ્સ middlewareની અલગ જવાબદારીઓને લગતી છે.

રીડાયરેક્ટ શું પસંદ કરે છે તે તપાસો: ઇચ્છિત કેનોનિકલ URL, અલગ સ્કીમ અથવા હોસ્ટનામ, લોગિન પૃષ્ઠ, અથવા પુનરાવર્તિત ચક્ર. સફળ પરિવહન પછી મળેલ 302 એ પ્રોક્સી કનેક્શન ખોલવામાં નિષ્ફળતાથી અલગ અવલોકન છે.

જ્યારે સામાન્ય રીડાયરેક્ટ હેન્ડલિંગ પુનઃસ્થાપિત થાય, ત્યારે Scrapy પ્રતિસાદના રિક્વેસ્ટ મેટાડેટામાં redirect_urls અને redirect_reasons ઉજાગર કરે છે. આ આખા ક્રોલ માટે રીડાયરેક્ટ નિષ્ક્રિય રાખ્યા વિના અંતિમ પરિણામ તરફનો માર્ગ સાચવી શકે છે.

અંતિમ પ્રતિસાદ એ એપ્લિકેશનનું ઇચ્છિત પૃષ્ઠ આપોઆપ નથી. ગંતવ્ય અને પ્રતિસાદનો સંદર્ભ રૂટિંગ નિદાન સાથે રાખો.