Alex Soto wrote:
no they are always the same, I simply go to browser do
https://localhost/hello/hello and I only push refresh button several times,
until the id appears. Then after some pushes it disappears again and
appears after some time again. So I think I am not changing the protocol
from https to http. In fact the browser complains about that the
certificate is homemade. So yes I think so.
In first mail I sent the Docker project
https://github.com/lordofthejars/apache-tomee-ssl just in case you didn't
know it.
Also one thing I done was to inspect the debugging file of mod_jk and I can
see the session id is not sent by mod_jk. But if it is because mod_jk
misses or not, I just don't know.
Alex, what I think that your tests show, is that sometimes *Apache httpd* is not setting
the SSL_SESSION_ID variable *as an Apache httpd environment variable*. Therefor, it is
(also) not passed by mod_jk to Tomcat.
That is also what Christopher was wondering, and that is why he asked you if you were
really sure that all your requests were HTTPS.
At this point, we also don't know why Apache httpd would in some cases not set this, but
the first thing is to find out if it is so, or not. And if it is so, then why ?
I believe that you can prove (or disprove) this by modifying the format of the Apache
access log. You can change it so that Apache httpd logs the content of this variable for
each request. Then you can again make a series of requests, and look at the Apache access
log to verify what happens.
Have a look here :
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats
and in particular at
%{FOOBAR}e The contents of the environment variable FOOBAR
You can also log the request protocol :
%H The request protocol
In summary : if you can show that Apache httpd is always setting what it should set, and
that sometimes mod_jk or Tomcat does not react to it, then the problem is with mod_jk or
Tomcat. But if Apache is sometimes not setting this, then the problem is with Apache, or
with something else in your setup. We are just trying to locate the issue correctly, and
to avoid spending time looking in the wrong places. (For us and for you).
El dc., 8 jul. 2015 a les 17:46, Christopher Schultz (<
ch...@christopherschultz.net>) va escriure:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alex,
On 7/8/15 10:18 AM, Alex Soto wrote:
I have tried what you mention. When SSL_Id is there both
request.getAttribute("javax.servlet, ....."); and
request.getAttribute("SSL_SESSION_ID"); returns valid sslId and in
the same way if one is null them the other one is null too so it
behaviour is consistent. About header approach always it is null,
probably something in rewrite is not set in header.
That sounds like httpd isn't providing the session id.
Are you absolutely sure that all of these requests are actually HTTPS
from the client? Do you ever switch between HTTPS and HTTP?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVnUWVAAoJEBzwKT+lPKRYEuYQAKdxOcVmVjJI3ul57zCWys43
KOO0cQddZUnuerb3zpBKSZn8ab6KCvVCs+usULV498OAjEUOaNl2PscgNCTbT7+G
YjxvXsz3TsgDvf5tIDexEFnuteb1/zxwmxl/yREjITTl4XnSx3MHPDH7n9vBiYlO
4iHFdmSF5K3CIAKweCjBYpsQdKAaVtmrfJzdpfOnop2tIlC+vAL2w5pgHOshm18Z
dR3oOcSztev9Vws4iOYQlwc47Cg3M0bxyZ/KyIOd2IAUp0vpc8KTa2Hym388VnP+
UfnCUeAOfF2eKfk4c0aXJ3VNAkfIMJ44gG9oSI2lAChk8dbK4PE41sZ+ykHPwJgR
gXXxXbAfrdbFuav2DtWAAoEUiGQGA4YuKqJxJMQa6LOI6sJ2+TXE/CIUkRwmijRs
NkKRDGy9KW9eVsF6N7gtCsDAoL/qbu8yr01d1A6hLiofiUj3EkweNBVs2dzMmt+N
WsY2Rbr9MdmYtaEcXI+uGsM5bLWatBDMxErnMCWve0QgrGiRjREns39ixuiuWpQI
qbBMGhLajjDxtLpd2mMiqXvLLXVIHKem3bJ/lxACiSmYlw/5/gDayoHt9KYYbxEu
adJ9wGjDRlaowokEKdGFd4GVndqoiK0NPfd2lgvSpZLuUL/qwoklTdiGr6zhkvT7
T+GAJuwkYY7GSgMplLrS
=vEii
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
