Ответ 1
Вот что происходит: клиент запрашивает страницу в первый раз, не отправляя никаких файлов cookie:
$ curl -v http://pixlshare.com/upload
Сервер не знает ничего о возможностях клиента на основе этого запроса, в частности, поддерживает ли он файлы cookie или нет. Следовательно, чтобы быть более безопасным, он отправляет оба cookie и JSESSIONID
в URL:
< Set-Cookie: JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C; Path=/; HttpOnly
...
<a wicket:id="image1Link" href="gallery/OKfzVk;jsessionid=25E7A6C27095CA1F560BCB2983BED17C">
Другими словами, контейнер сервлетов защищает JSESSIONID
до каждого URL-адреса, на всякий случай, если клиент не поддерживает файлы cookie.
Итак, почему JSESSIONID
исчезает во втором запросе? Потому что теперь клиент отправляет cookie в HTTP-запрос и сервер знает, что клиент обрабатывает их. При этом JSESSIONID
больше не требуется.
$ curl -v -b JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C http://pixlshare.com/upload
> Cookie: JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C
...
<a wicket:id="image1Link" href="gallery/OKfzVk">
С другой стороны, если клиент не поддерживает файлы cookie, сервер будет продолжать переписывать URL-адреса.
Это не проблема с калитки, это функция Tomcat.
BTW (со своего сайта JavaScript):
path = path.replace(/^C:\\fakepath\\/i, '');
Что такое f... ake?