Java lettura non codificato URL dal Servlet

Question

Diamo presumere che ho stringa come '= & /; # +%?' Ad essere una parte del mio URL, diciamo così:

example.com/servletPath/someOtherPath/myString/something.html?a=b&c=d#asdf

dove myString è la stringa sopra. Ho codificato parte critica in modo URL assomiglia

example.com/servletPath/someOtherPath/%3D%26%3F%2F%3B%23%2B%25/something.html?a=b&c=d#asdf

Fin qui tutto bene.

Quando sono in servlet e ho letto nessuno dei request.getRequestURI(), request.getRequestURL() o request.getPathInfo(), restituito il valore è già decodificato, in modo da ottenere strilng come

someOtherPath/=&?/;#+%/something.html?a=b&c=d#asdf

e non riesco a distinguere tra i caratteri speciali reali e quelli codificati.

Ho risolto problema particolare vietando sopra caratteri del tutto, che funziona in questa situazione, ma mi chiedo ancora c'è un modo per ottenere l'URL non decodificata in classe servlet.

ANCORA UN ALTRO EDIT: Quando ho colpito questo problema ultima sera ero troppo stanco per notare ciò che sta realmente accadendo, che è ancora più bizzarro Ho servlet mappato su, dicono / servletPath / * dopo che posso mettere quello che voglio e ottenere il mio servlet rispondendo a seconda del resto di un percorso, eccezione quando c'è% 2F nel percorso. In tal caso, richiesta non colpisce il servlet , e ottengo 404! Se metto '/' invece di% 2F funziona OK. Sono in esecuzione Tomcat 6.0.14 su Java su Linux 1.6.0-04.

Answer 1

C'è una differenza fondamentale tra '% 2F' e '/', sia per il browser e il server.

La specifica HttpServletRequest dice (senza alcuna logica, AFAICT):

• getContextPath: non decodificato
• getPathInfo: decodificato
• getPathTranslated: non decodificato
• getQueryString: non decodificato
• getRequestURI: non decodificato
• getServletPath: decodificato

Il risultato di getPathInfo () dovrebbe essere decodificato, ma il risultato di getRequestURI () deve non decodificare. Se lo è, il servlet container sta rompendo le specifiche (come Wouter Coekaerts e Francois Gravel ha sottolineato giustamente). Quale versione di Tomcat stai correndo?

Fare le cose ancora più confuse, le versioni di Tomcat attuali rifiutano i percorsi che contengono codifiche di alcuni caratteri speciali, per motivi di sicurezza .

Answer 2

Se c'è un %2F nel decodificato url, significa che il codificati url %252F contenute.

Dal %2F è / Perché non basta dividere il "\/" e non preoccuparsi di codifica URL?

Answer 3

Secondo il Javadoc , getRequestURI non dovrebbero decodificare la stringa. D'altra parte, getServletPath restituisce una stringa decodificata. Ho provato questo utilizzando localmente Jetty e si comporta come descritto nel documento.

Quindi ci potrebbe essere qualcos'altro in gioco nella vostra situazione dal momento che il comportamento che stai descrivendo non corrisponde la documentazione solarium.

Answer 4

Sembra che si sta cercando di fare qualcosa Resty (utilizzare Jersey). Può vi basta analizza fuori le parti iniziali e finali del URL per ottenere i dati che stai cercando?

url.substring (startLength, url.length - endLength);

Answer 5

Aggiornamento: questa risposta è stato originariamente torto affermando che '/' e '% 2F' in un percorso dovrebbe sempre essere trattati allo stesso modo. Sono infatti diversi perché un percorso è un elenco di segmenti / -separated.

Non si dovrebbe avere a fare la differenza tra un carattere codificato e non codificato in la parte percorso del URL. Non v'è alcun carattere all'interno del percorso che può avere un significato particolare in un URL. Per esempio. '% 2F' deve essere interpretato lo stesso di '/', e un browser accede a un tale URL è libero di sostituire uno con l'altro come meglio ritiene opportuno. Fare la differenza tra di loro è rompere lo standard di come URL sono codificati.

l'URL completo, è necessario fare la differenza tra i caratteri di escape e non di fuga per diversi motivi, tra cui:

• Per vedere dove finisce la parte percorso. Perché un? codificati nel percorso non deve essere visto come la fine.
• all'interno della stringa di query. Perché parte del valore di un parametro potrebbe contenere '&' o '=', ...
• All'interno di un percorso, un '/' separa due segmenti mentre '% 2F' può essere contenuta all'interno di un segmento

Java si occupa bene con i primi due casi:

• getPathInfo() che restituisce solo la parte percorso, decodificato
• getParameter(String) per accedere a parti della parte di query

Non si tratta così bene con il terzo caso. Se si vuole fare una differenza fra '/' come la separazione di due segmenti di percorso, ed un '/' all'interno di un segmento di percorso (% 2F), allora si può non rappresentare in modo coerente il percorso come una stringa decodificata. È possibile rappresentare come una stringa codificata (ad esempio "foo / bar% 2Fbaz"), o come un elenco di segmenti decodificati (ad esempio "foo", "bar / baz"). Ma perché getPathInfo () API promette di fare proprio questo (una stringa decodificata), non ha altra scelta se non per il trattamento di '/' e '% 2F' come lo stesso.

Per usuali applicazioni web, questo è bene. Se siete nel raro caso in cui si ha realmente bisogno di fare la differenza, si può fare il proprio parsing di URL, ottenendo la versione grezza con getRequestURI(). Se che si dà l'URL decodificato come si sostiene, allora significa che c'è un bug nell'implementazione servlet che si sta utilizzando.