декодирование URL JBOSS

Question

У нас есть сервлет, размещенный на jboss, который работает по HttpServletRequest. Но иногда мы получаем запросы, которые не декодируются jboss, и когда мы выполняем getQueryParam для HttpServletRequest, мы получаем null Журнал доступа jboss показывает URL в закодированном виде. Обычно, когда все работает гладко, URL-адрес отображается расшифрованным в журнале доступа. e.g.:

Это был проблемный запрос:

127.0.0.1 [13/Apr/2009:14:18:53 +0000] GET /redirectService//%3Fclient_id=3&redirect_url=http%253A%252F%252Fwww.amazon.de%252Fgp%252Fsearch%253Fie%253DUTF8%2526keywords%253DMicrosoft+Office+2007%2526search-alias%253Dsoftware%2526 HTTP/1.1 'null' 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)'

Это был правильный запрос:

127.0.0.1 [13/Apr/2009:14:19:37 +0000] GET /redirectService//?client_id=3&redirect_url=http%3A%2F%2Fwww.amazon.de%2Fgp%2Fsearch%3Fie%3DUTF8%26keywords%3DMAGIX+Video+deluxe+2008%26search-alias%3Dsoftware%26 HTTP/1.1 'http://www.google.de/search?hl=de&q=magix+video+deluxe+2008&meta=&aq=3&oq=%22magix%22' 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)'

Не могли бы мы пропустить некоторые настройки декодирования jboss или это просто случай злоумышленника?

Answer 1

Мы зарегистрировали user-agent, в большинстве случаев это какой-то подозрительный «XXXagentXXX», но настоящий Mozilla (как указано выше) в других. Реферер "-" для всех этих запросов. Однако есть одна любопытная вещь, которую я заметил сегодня. Мы перенаправляем наши запросы из apache (80) в jboss. Журнал доступа Apache показывает приведенный выше запрос как полностью закодированный:

GET /r/%3Fclient_id%3D3%26redirect_url%3Dhttp%253A%252F%252Fwww.amazon.de%252Fgp%252Fsearch%253Fie%253DUTF8%2526keywords%253DCyberlink%2BPower%2BDirector%2526search-alias%253Dsoftware HTTP/1.0" 400 965 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10)"

в то время как в журнале доступа jboss есть все, кроме% 3F, декодированного. Теперь это заставляет меня думать, что apache испортит где-то в декодировании?

Answer 2

Трудно сказать, правда.

Клиент, похоже, расшифровывает знак вопроса в "% 3F", но не в амперсанд. Подозрительно, не правда ли? Это похоже на глючный клиент IMO. Может быть, непортативный javascript, может быть какая-то ошибка перезаписи URL на стороне веб-сервера или более эзотерическая причина ... неправильно работающий плагин для браузера.

Чтобы исключить непортативный javascript, зарегистрируйте user-agent и сравните результаты. Чтобы исключить ошибку переписывания URL, войдите в систему referer.

AFAIK, поведение декодера URL жестко задано. Кодировка строки может измениться, если URI записан не в ascii или не в iso88591, но это не то, что вам нужно. То, что кодирует знаки вопроса, но не может кодировать амперсанды, ускользает от меня.