È una barra ("/") equivalente a una barra codificata ("% 2F") nella porzione di percorso di un URL HTTP

Question

Ho un sito che tratta "/" e "% 2F" nella porzione percorso (non la stringa di query) di un URL in modo diverso. È una cosa brutta da fare secondo la RFC o il mondo reale?

Chiedo perché continuo a correre piccole sorprese con il framework web che sto usando (Ruby on Rails) così come i livelli sottostanti (Passenger, Apache, ad esempio, ho dovuto abilitare "ALLOW_ENCODED_SLASHES" per Apache) . Ora mi sto appoggiando a eliminare completamente le barre codificate, ma mi chiedo se dovrei archiviare segnalazioni di bug in cui vedo strani comportamenti che coinvolgono le barre codificate.

Quanto al perché ho le barre codificate, in primo luogo, in fondo io sono rotte come questo:

:controller/:foo/:bar 

dove: foo è qualcosa come un percorso che può contenere barre. Ho pensato che la cosa più semplice da fare sarebbe stata la sola URL di escape foo in modo che le barre fossero ignorate dal meccanismo di routing. Ora ho dei dubbi, ed è abbastanza chiaro che i framework non supportano veramente questo, ma secondo la RFC è sbagliato farlo in questo modo?

Ecco alcune informazioni che ho raccolto:

RFC 1738 (URL):

Di solito un URL ha la stessa interpretazione quando un ottetto è rappresentato da un personaggio e quando è codificato. Tuttavia, questo non è vero per i caratteri riservati: la codifica di un carattere riservato per uno schema particolare può cambiare la semantica di un URL.

RFC 2396 (URI):

Questi caratteri sono chiamati "riservati", dal momento che il loro utilizzo all'interno del componente URI è limitata allo scopo riservata. Se i dati di un componente URI sono in conflitto con lo scopo riservato, i dati in conflitto devono essere preceduti da escape prima di formare l'URI.

(si fa sfuggire qui media qualcosa di diverso che codifica il carattere riservato?)

RFC 2616 (HTTP/1.1):

personaggi diversi da quelli nella "riservata" e "non sicuri "set (vedi RFC 2396 [42]) sono equivalenti alla loro codifica" "%" HEX HEX ".

C'è anche this bug report per Rails, dove sembrano aspettarsi che la barra codificata a comportarsi in modo diverso:

destro, mi aspetto risultati diversi perché sono indicando diverse risorse.

Cerca il file letterale "foo/bar" nella directory principale. La versione senza escape sta cercando la barra dei file nella directory pippo.

E 'chiaro dalle RFC che raw vs encoded è l'equivalente per i caratteri non riservati, ma qual è la trama per i caratteri riservati?

Answer 1

Dai dati raccolti, tenderei a dire che codificati "/" in un uri sono pensati per essere visti come "/" di nuovo a livello di applicazione/cgi.

Vale a dire, se si utilizza apache con mod_rewrite, ad esempio, non corrisponderà al modello che prevede barre contro URI con barre codificate in esso. Tuttavia, una volta richiamato il modulo/cgi/... appropriato per gestire la richiesta, è in grado di eseguire la decodifica e, ad esempio, recuperare un parametro che include le barre come primo componente dell'URI.

Se l'applicazione utilizza questi dati per recuperare un file (il cui nome contiene una barra), probabilmente è una cosa negativa.

Per riassumere, trovo perfettamente normale osservare una differenza di comportamento in "/" o "% 2F" poiché la loro interpretazione verrà eseguita a diversi livelli.

Answer 2

Ho anche un sito con numerosi URL con caratteri urlencoded. Sto scoprendo che molte API Web (inclusi gli strumenti per i webmaster di Google e diversi moduli Drupal) inciampano sui caratteri con l'urlencoded. Molte API decodificano automaticamente gli URL a un certo punto del loro processo e quindi usano il risultato come URL o HTML. Quando trovo uno di questi problemi, di solito raddoppio i risultati (che trasforma% 2f in% 252f) per quell'API. Tuttavia, questo interromperà altre API che non si aspettano la doppia codifica, quindi questa non è una soluzione universale.

Personalmente mi sto liberando del maggior numero possibile di caratteri speciali nei miei URL.

Inoltre, sto usando numeri ID nei miei URL che non dipendono da urldecoding:

example.com/blog/my-amazing-blog%2fstory/yesterday

diventa:

example.com/blog/12354/my-amazing-blog%2fstory/yesterday

in questo caso, il mio codice utilizza solo 12354 per cercare l'articolo e il resto dell'URL viene ignorato dal mio sistema (ma è ancora usato per SEO.) Inoltre, questo numero dovrebbe apparire PRIMA dell'URL non utilizzato mponents. in questo modo, l'url funzionerà ancora, anche se% 2f viene decodificato in modo errato.

Inoltre, assicurarsi di utilizzare i tag canonici per garantire che gli errori URL non si traducano in contenuti duplicati.

Answer 3

Se si utilizza Tomcat, aggiungere "-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = true" nelle proprietà della macchina virtuale.

https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

Answer 4

La storia di %2F vs / era che, secondo l'iniziale W3C recommendations, barre «deve implicare una struttura gerarchica»:

Esempio 2

gli URI

http://www.w3.org/albert/bertram/marie-claude

e

http://www.w3.org/albert/bertram%2Fmarie-claude

non sono identici, come nel secondo caso la barra codificata non fa hanno un significato gerarchico.

Answer 5

Cosa fare se :foo nella sua forma naturale contiene le barre? Non vorresti che fosse che la distinzione che la raccomandazione sta tentando di preservare? It specifically notes,

La somiglianza con unix e altre convenzioni di nome di file di sistema operativo disco deve essere assunta come puramente casuale, e non dovrebbe essere preso per indicare che URI devono essere interpretati come nomi di file.

Se uno è stato la costruzione di un interfaccia online per un programma di backup, e ha voluto esprimere il percorso come una parte del sentiero URL, avrebbe senso per codificare i tagli nel percorso del file, come quello è non fa davvero parte della gerarchia della risorsa e, ancora più importante, la route . /backups/2016-07-28content//home/dan/ perde la radice del filesystem nella doppia barra. Sfuggire alle barre è il modo appropriato per distinguere, mentre lo leggo.