Utilizarea curl pentru a solicita un URL care redirecționează către un URL relativ cu etichetă de ancorare (Administrarea sistemului, Http, Redirecționare, Curl, Http Headers)

jrdioko a intrebat.
a intrebat.

Folosesc curl pentru a solicita un URL care redirecționează către un alt URL folosind o etichetă Location: linie ca:

Location:/path/to/resource#name

După cum înțeleg, acea linie din răspunsul de redirecționare nu este valabilă conform specificațiilor HTTP, astfel încât apelul curl în ansamblu eșuează în mod înțelegător (în acest caz, cu un cod de răspuns 400). Cu toate acestea, solicitarea URL-ului cu wget sau cu un browser web redă pagina cu succes (presupun că prin euristica care completează calea absolută sau elimină eticheta de ancorare înainte de redirecționare).

Există ceva ce pot face pentru ca curl să facă același lucru (să facă ceea ce este necesar pentru a urma cu succes redirecționarea, chiar dacă este „oficial” malformată)?

Editați: Câteva detalii suplimentare. Codul de răspuns final este 400 (nu 404 sau altceva). Atunci când fac o cerere HEAD (cu curl -I -L), primesc un 302 Found (cu Location: /Error) care redirecționează către un 500 Server Error. Cu toate acestea, dacă fac o cerere obișnuită (fără -I dar cu opțiunea -L ), primesc un http_code (în curl’s --write-out) de 400. Deci se pare că, în acest caz, cererile HEAD funcționează diferit față de GET-urile standard.

Comentarii

  • Spuneți că „apelul general curl” are ca rezultat un „cod de răspuns 400”. Vă referiți la un cod 400 (solicitare greșită) sau la un alt cod de răspuns 4**, cum ar fi 404 (nu a fost găsit)? Încep să cred că totul funcționează așa cum ar trebui să fie, dar pagina către care sunteți redirecționat nu există (404), este interzisă (403) sau ceva similar. Ce cod de răspuns este returnat atunci când folosiți curl pentru a solicita direct pagina către care sunteți redirecționat? –  > Por Tom Hudson.
2 răspunsuri
Tom Hudson

Din câte am înțeles, curl nu urmărește în mod implicit Location headers.

Puteți activa un astfel de comportament utilizând opțiunea -L sau --location comutator. Astfel:

[email protected]:~▶ curl -I -L http://shell/redirect.php     
HTTP/1.1 302 Found
Date: Tue, 17 Jan 2012 00:13:54 GMT
Server: Apache/2.2.17 (Ubuntu)
X-Powered-By: PHP/5.3.5-1ubuntu7.2
Location: /target.html#someAnchor
Content-Type: text/html

HTTP/1.1 200 OK
Date: Tue, 17 Jan 2012 00:13:54 GMT
Server: Apache/2.2.17 (Ubuntu)
Last-Modified: Tue, 17 Jan 2012 00:10:37 GMT
Accept-Ranges: bytes
Content-Length: 7
Content-Type: text/html

Notă: -I este utilizat doar pentru a afișa antetele și nu conținutul paginii. Am testat acest lucru folosind curl 7.21.6 care rulează pe Ubuntu.

Comentarii

  • Îmi cer scuze pentru neclaritate, folosesc -L pentru a urmări redirecționările. Problema este că se poate întâmpla ca redirecționările malformate Location: linie face ca apelul curl să eșueze, în timp ce wget și browserele reușesc. Exemplul tău pare să funcționeze totuși, ciudat… –  > Por jrdioko.
  • Poți să postezi antetele complete pentru cerere și răspuns? (Doar întregul lucru cu -I într-adevăr) pentru comparație? –  > Por Tom Hudson.
  • Întrebare editată pentru a adăuga mai multe detalii. –  > Por jrdioko.
jrdioko

Am descoperit că această problemă particulară apare cu curl 7.15.5, dar funcționează bine cu curl 7.21.0. Deci, trebuie să fi existat o remediere de erori sau o caracteristică implementată între timp care să o rezolve. Dacă cineva știe exact ce patch sau schimbare a rezolvat acest lucru, ar fi apreciat!

Comentarii