Errore 405 su un link: confronta HEAD e GET

Non dichiarare il link guasto solo per il numero

Il browser apre una pagina, ma un controllo restituisce 405. La differenza richiede un’indagine, non la cancellazione immediata del link. Secondo la risposta ricevuta, il metodo richiesto non è supportato per quella risorsa. Questo non conferma che il contenuto esista, sia pubblico o sia disponibile per ogni visitatore. Conserva l’indirizzo esatto e annota quale strumento ha prodotto il risultato.

In una domanda su Stack Overflow, passare da GET a HEAD per controllare link causava errori 405. Un’altra domanda su Reddit descrive falsi positivi di un programma di verifica. Sono problemi segnalati, non prove della causa nel tuo caso. Questa procedura confronta richieste e contenuto prima di decidere se correggere il link, il verificatore o la configurazione del sito.

Che cosa cambia tra HEAD e GET

GET richiede una rappresentazione della risorsa; HEAD richiede i metadati corrispondenti a GET senza il corpo di quella risposta. MDN documenta la distinzione. Richiedere solo intestazioni può ridurre il trasferimento, ma non permette di leggere la pagina né confermare il documento previsto. Non garantisce neppure che un’applicazione o intermediario gestisca correttamente entrambi i metodi. Annota il metodo usato quando viene rifiutato.

RFC 9110 richiede che una risposta 405 includa Allow con i metodi attualmente supportati dalla risorsa. Controlla l’intestazione se lo strumento la mostra. Se manca, documentane l’assenza: non inventare valori e non supporre che abilitare ogni metodo risolva il problema. La risposta di esempio è illustrativa, non proviene da un sito reale. Allow non sostituisce la prova del metodo necessario.

HTTP/1.1 405 Method Not Allowed
Allow: GET

Confronta richieste che sai interpretare

Se amministri il sito e sai utilizzare un terminale, confronta HEAD e GET sullo stesso indirizzo pubblico di consultazione. I comandi mostrano le intestazioni; il secondo scarta il corpo dopo averlo ricevuto e può quindi scaricare dati. Sostituisci example.invalid con la tua pagina autorizzata. Il dominio è fittizio, non un servizio disponibile da controllare. Non testare acquisti, cancellazioni o disconnessioni.

Mantieni uguali URL e condizioni controllabili. Annota ora, metodo, stato ed eventuale reindirizzamento. I comandi non seguono reindirizzamenti: esaminane prima la destinazione e decidi se ripetere lì. Non aggiungere credenziali e non copiare cookie privati in strumenti pubblici. Un browser autenticato e una richiesta anonima da un altro computer non sono un confronto equivalente. Registra questa differenza prima di attribuire il problema al metodo.

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

Interpreta senza conclusioni affrettate

Se HEAD riceve 405 e GET riceve 200 in condizioni comparabili, puoi affermare che le due richieste hanno ottenuto risposte diverse. Devi ancora aprire la pagina e verificarne il contenuto. Se anche GET riceve 405, non hai dimostrato un problema esclusivo di HEAD. Se restituisce 404, il precedente controllo HEAD non provava l’esistenza della pagina richiesta. Separa ogni osservazione dalla tua ipotesi.

Non cambiare un modulo da POST a GET per eliminare l’errore: potresti modificarne il funzionamento ed esporre dati nell’indirizzo. Non disattivare protezioni né abilitare metodi di scrittura per comodità. Sul tuo sito, consegna i risultati a chi esamina percorsi e regole del server. Su un sito altrui, richiedi un link pubblico appropriato o segnala il problema senza informazioni sensibili.

Aggiungi il controllo di WikiURL

Incolla l’indirizzo pubblico completo nel verificatore URL di WikiURL e conserva lo stato HTTP e l’indirizzo finale rilevato. È un’osservazione aggiuntiva dal server del servizio. Non presumere che riproduca browser, sessione o comandi precedenti. L’interfaccia non offre la scelta manuale fra HEAD e GET: non attribuirle un confronto che non presenta.

Apri poi la destinazione reale nel browser e conferma che sia la pagina prevista per il suo pubblico. Se verificatore e browser divergono, conserva entrambi i risultati con le relative condizioni. Un 200 non certifica contenuto o sicurezza; un singolo 405 non decide da solo la rimozione del link. Raccogli prove utili per correggere il componente specifico, senza trasformare un’etichetta in una diagnosi completa.

Conserva una decisione verificabile prima della condivisione

Prepara un breve registro: URL, data, strumento, metodo conosciuto o non osservato, stato, destinazione finale e contenuto verificato. Segna come in sospeso le prove mancanti. Conserva le intestazioni necessarie senza token, cookie o dati personali. Per un’altra persona incaricata della verifica, fornisci questo riepilogo e il comportamento atteso, non una conclusione ancora priva di prove sufficienti.

Dopo una correzione concreta, ripeti un controllo proporzionato e conferma il contenuto prima di abbreviare l’indirizzo o generare un QR con WikiURL. Questi formati facilitano la condivisione, ma non cambiano i metodi ammessi dal server né riparano la risorsa. Conserva il link di riferimento insieme al file pubblicato. Potrai distinguere differenze fra client, metodi rifiutati e destinazioni sbagliate senza eliminare un indirizzo valido sulla base di una sola risposta.