Eu percebi isso.
Adicione isto à configuração do VHost:
ProxyPassReverseCookiePath /webapp /
Estou tendo alguns problemas para fazer com que os cookies funcionem ao usar um ProxyPass para redirecionar o tráfego na porta 80 para um aplicativo da Web hospedado por meio do Tomcat.
Minha motivação para ativar os cookies é livrar-me do parâmetro "jsessionid=" que é anexado às URLs.
Eu ativei cookies no meu context.xml no META-INF / para meu aplicativo da Web.
Quando eu acesso o webapplication através do link ele funciona como esperado, o parâmetro jsessionid não é visível no URL, mas é armazenado em um cookie. / p>
Ao acessar meu site por meio de um host virtual apache2, os cookies parecem não funcionar, porque agora o "jsessionid" está sendo anexado às URLs. Como posso resolver este problema?
Aqui está minha configuração do VHost:
<VirtualHost *:80> ServerName somedomain.no ServerAlias www.somedomain.no <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPreserveHost Off ProxyPass / http://localhost:8080/webapp/ ProxyPassReverse / http://localhost:8080/webapp/ ErrorLog /var/log/apache2/somedomain.no.error.log CustomLog /var/log/apache2/somedomain.no.access.log combined </VirtualHost>
EDIT: O cookie está sendo definido quando eu visito do link , mas o cookie tem seu caminho definido como "/webapp".
Remapear URLs é o que mais causa problemas nos aplicativos, porque em muitos lugares os caminhos são inconsistentes. É muito melhor evitar fazer isso e fazer com que o visitante acesse diretamente sua página. Por exemplo, você poderia escrever uma regra de redirecionamento que afirma que quando um visitante acessa "/", ele é redirecionado para "/ webapp /" e dessa forma ele usa o caminho real e não o remapeado.
Com seu remapeamento, você sempre encontrará problemas como este. Algumas vezes você se pergunta por que obtém imagens quebradas e descobre "/ webapp / img / ..." em redirecionamentos gerados por aplicativos. Em outros momentos, você verá que seu aplicativo está ciente de seu caminho e produz / locais de webapp por si só, levando a / webapp / webapp no navegador do visitante, etc ... Estes são os horrores que causam pelo menos metade do admin trabalhe em lugares onde o remapeamento de URL é usado, então você deve realmente considerar alternativas antes que seja tarde demais para mudar.