Hi at the end it seems apache is doing something (wrong or not) HTTP/1.1 - 172.17.42.1 - - [09/Jul/2015:09:15:06 +0000] "GET /hello/hello HTTP/1.1" 200 89
HTTP/1.1 1b17f16f8ae73c1b4d706c1598aadb596db610bbdaeb1cd967e0bea98ec2abcb 172.17.42.1 - - [09/Jul/2015:09:15:34 +0000] "GET /hello/hello HTTP/1.1" 200 209 Notice how ssl session id is printed when it is ready. So now it is time to start a discussion with apache and why this is happening. Thank you so much for all your support. Alex. El dj., 9 jul. 2015 a les 0:22, André Warnier (<a...@ice-sa.com>) va escriure: > 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 > >
