Re: From HTTP to HTTPS request.getHeader(referer)
Hello and thank you for your answers. I would like to say that my problem is solved (even though I would like to answer the remarks you made). I can't really tell what combination of adjustments (see my previous posts) are responsible for it. I just did things with more care than when I do things hastily (or just to try something). I'm saying this because (see below) I thought sendRedirect() was working only if I passed it the complete HTTPS URL of the JSP I was willing to redirect to user towards. I appears that now, it works if I only pass the JSP page name to sendRedirect() (like I did in the past when dealing with HTTP requests only). So, I don't really know what to think :'/ Christopher Schultz wrote: If you are already in HTTPS protocol and don't want to switch, then you shouldn't have to specify the protocol in the redirect. Well, indeed, it looks like I don't have to specify the protocol anymore... (see my comment above). Christopher Schultz wrote: Yes, they don't really help in any way because they don't describe use cases. You didn't provide anything like I want X, I tried Y, and Z happened so it's hard to help you out. Well, it troubles me because, I was willing to give you some relevant information (I just often do not know which and I also understand it's not easy for you to understand my stuff when you only get pieces of it). I wanted to know if my HTTPS configuration for a standalone Tomcat serving all the pages of some webapps with the HTTPS protocol is fine or not. The configuration details I sent previously are really the only thing I do (to have Tomcat serve the webapps JSPs with the HTTPS protocol)... Normally, if I'm not mistaken, I can switch back to HTTP by: 1) Removing the security-constraint element from the webapp web.xml file. 2) Replacing the three connectors: Connector port=quot;443quot; [...] lt;Connector port=quot;80quot; [...] lt;Connector port=quot;8009quot; [...] from the Tomcat quot;server.xmlquot; file (see the post in which I posted the config) and replace them with the two connectors: lt;Connector port=quot;80quot; protocol=quot;HTTP/1.1quot; connectionTimeout=quot;2quot; redirectPort=quot;8443quot; / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / To try to give you an answer: this is probably a typical use case in the webapp: - The user has requested a JSP page x.jsp: it can see this page properly in its browser. - The user submits this JSP's form (which has an action attribute mapped with a servlet in web.xml). - The doPost() method of the servlet is invoked. - Some instructions are executed (database access for example). - Before exiting (return;) the doPost(), I execute response.sendRedirect(y.jsp). This used to fail before: I don't remember the error but the page y.jsp wasn't served at all. This is working now. I thought that the two things I configure (1. security-constraint element the web.xml of the webapp and 2. the connectors Tomcat server.xml) are just enough to show what I do to make Tomcat serve the the JSPs of some webapps with the HTTPS protocol... If this config looks good and if what I wrote just now doesn't bring anything new to the table, please ignore it since its working now. Christopher Schultz wrote: Look at your access log to file out what's going on when you request an http:// URL. Below is what I can find in the Tomcat access logs file: Requested resource: http://host/webapp/welcome.jsp 192.168.2.19 - - [06/Nov/2014:11:06:03 +0100] GET /webapp/welcome.jsp HTTP/1.1 302 - 192.168.2.19 - - [06/Nov/2014:11:06:19 +0100] GET /webapp/welcome.jsp HTTP/1.1 200 5361 Requested resource: https://host/webapp/welcome.jsp 192.168.2.19 - - [06/Nov/2014:11:08:06 +0100] GET /webapp/welcome.jsp HTTP/1.1 200 5361 Should the HTTPS protocol be mentioned somewhere in this file? Just reading this, can someone (you for instance) infer that the page welcome.jsp was served using the HTTPS protocol? Is there another log file where this can be checked? Thank you for mentioning the 302 response: not that it particularly enlightens me but maybe one day it will be clearer for me. Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782p5025082.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail:
Re: From HTTP to HTTPS request.getHeader(referer)
Hi, Christopher Schultz wrote: If you want to switch protocols I don't think I want that... but maybe I do not understand properly what you mean... For the webapp I've been considering in that thread, I would like Tomcat to serve pages only via HTTPS. I do not want some pages to be served via HTTP and some others to be served via HTTPS. I don't know if it clarifies my point... Have you had a little time to have a look at the configuration files I posted yesterday (complete server.xml and excerpt from the webapp's web.xml)? 1) In web.xml, I set the CONFIDENTIAL security constraint which, as far as I understood, imposes the use of the HTTPS protocol to serve the JSP pages of the webapp. 2) Ideally, I would like the webapp users to enter HTTPS URLs in their browser URL bar/directly click URLs like https://host/webapp/a-page.jsp. But I also would like them to be able to enter HTTP URLs like http://host/webapp/a-page.jsp which are, to my understanding automatically transformed into https://host/webapp/a-page.jsp thanks to the server.xml configuration line: Connector port=80 enableLookups=false redirectPort=443/ I realize I do not know what happens to the request in that case (http://host/webapp/a-page.jsp). Is it encoded or not? Terence M. Bandoian wrote: I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. I didn't know that. I thought there was one HTTP(S) request and one HTTP(S) response only. How can the mechanism you describe above affect the use of HTTPS for a webapp with the CONFIDENTIAL security constraint on a standalone Tomcat server? I'm using sendRedirect() in a very straightforward way I think. I use some sort of pipelines for a subset S of JSPs in the webapp: 1) Given a JSP s in S, it contains a form with an action attribute mapped via web.xml to a servlet L. 2) The servlet L implements either a doPost() or (rarely) a doGet() method. 3) Given what was submitted via the form, work is performed in the servlet. 4) When the servlet work is done and depending on the result (success 1, ..., success n / error 1, ..., error n), the servlet redirects towards the next JSP using the method sendRedirect(). Is there a temporary redirect response to the client in that case? Is this behavior documented somewhere? I could totally benefit from a good documentation... Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782p5024951.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 11/4/14 5:46 AM, Léa Massiot wrote: Christopher Schultz wrote: If you want to switch protocols I don't think I want that... but maybe I do not understand properly what you mean... For the webapp I've been considering in that thread, I would like Tomcat to serve pages only via HTTPS. I do not want some pages to be served via HTTP and some others to be served via HTTPS. I don't know if it clarifies my point... If you are already in HTTPS protocol and don't want to switch, then you shouldn't have to specify the protocol in the redirect. Have you had a little time to have a look at the configuration files I posted yesterday (complete server.xml and excerpt from the webapp's web.xml)? Yes, they don't really help in any way because they don't describe use cases. You didn't provide anything like I want X, I tried Y, and Z happened so it's hard to help you out. 1) In web.xml, I set the CONFIDENTIAL security constraint which, as far as I understood, imposes the use of the HTTPS protocol to serve the JSP pages of the webapp. Yes. Tomcat should therefore handle redirecting the user from HTTP to HTTPS on the first request. 2) Ideally, I would like the webapp users to enter HTTPS URLs in their browser URL bar/directly click URLs like https://host/webapp/a-page.jsp. But I also would like them to be able to enter HTTP URLs like http://host/webapp/a-page.jsp which are, to my understanding automatically transformed into https://host/webapp/a-page.jsp thanks to the server.xml configuration line: Connector port=80 enableLookups=false redirectPort=443/ I realize I do not know what happens to the request in that case (http://host/webapp/a-page.jsp). Is it encoded or not? Tomcat should redirect the user to https://host/webapp/a-page.jsp. Your JSP code will not run in this case until the HTTPS request has been received. Look at your access log to file out what's going on when you request an http:// URL. Terence M. Bandoian wrote: I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. I didn't know that. I thought there was one HTTP(S) request and one HTTP(S) response only. How can the mechanism you describe above affect the use of HTTPS for a webapp with the CONFIDENTIAL security constraint on a standalone Tomcat server? Read about what an HTTP residrect does. I'm using sendRedirect() in a very straightforward way I think. +1 I use some sort of pipelines for a subset S of JSPs in the webapp: 1) Given a JSP s in S, it contains a form with an action attribute mapped via web.xml to a servlet L. 2) The servlet L implements either a doPost() or (rarely) a doGet() method. 3) Given what was submitted via the form, work is performed in the servlet. 4) When the servlet work is done and depending on the result (success 1, ..., success n / error 1, ..., error n), the servlet redirects towards the next JSP using the method sendRedirect(). I would say this is a pretty standard way to do things: the form-handler should do its job and then *redirect* (not forward) to another page. Otherwise, re-loading the next page on the client will re-submit the form, which is rarely what you want to have happen. Is there a temporary redirect response to the client in that case? Is this behavior documented somewhere? I could totally benefit from a good documentation... A temporary redirect is a term right from the HTTP spec. It means a 302 response code which has a special meaning to clients. Google for http status codes and read about them all. It's good to know these things. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWPTvAAoJEBzwKT+lPKRYzBUQAL409gE2n0wI8t3B5JBdvXoB y6RjmdT2mD4WWVlsqoDmzXP6M3ziVDifsn+oj9bggHGtRaA8RKCXVGvFHrq+WQ4b j2r8hdGoUkbPBOY68m0F+IFOceTn3UWw84kjySfLtfyqldkvoBoRXBPTKq4aviok eMMnRmCr6XhwKfMY9lVaqFJQ+XwLViij4bqvu/oAmS71jzruBTVv1ZhYMGhICBcq 10jA9ow0XhyHcEcgwZAFJ0U8xqKdNHYWgvjj83TY6lkih0Gvo/pjEWYMFfJN4aR1 U8feGtKtiy5H7JQwlA3x7vDniqzop8dnyZM83pEtsIUV+GKihXVp+n0glSt2ryPW c5fUF58JtpRYk/3k/3vvwl4NU+FmcyXLjDl1EgUD8icDGH0lUZH+tYvHZCR02h1/ v8fn+d4WUdpDUtIkJSdEDSCbVhdmTSZdxPcbRby1GwZWr82wWBM3lWEXSSwB7+vq Cnd895ithqp42vWpIIzs5Won9DdvZ9EgPfBBsEtA7+VGiz+N9wXVQg0TZhvj9JxK 3foXkmGZEZE/xHLs822UqZ9YAiCkbQmfQbZARSppkBBWqhuXdG9opaMvOMwdFJaY 1SutJpFczUqaxDrvq8HSaGKVA9sYxc1phXM3VkvUkvGyXddFQdLkkU2C44NOjSpV DMQNpgPedI0rQRZSCuoO =6hs8 -END PGP SIGNATURE- -
Re: From HTTP to HTTPS request.getHeader(referer)
On 11/4/2014 4:46 AM, Léa Massiot wrote: Hi, Terence M. Bandoian wrote: I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. I didn't know that. I thought there was one HTTP(S) request and one HTTP(S) response only. How can the mechanism you describe above affect the use of HTTPS for a webapp with the CONFIDENTIAL security constraint on a standalone Tomcat server? I'm using sendRedirect() in a very straightforward way I think. I use some sort of pipelines for a subset S of JSPs in the webapp: 1) Given a JSP s in S, it contains a form with an action attribute mapped via web.xml to a servlet L. 2) The servlet L implements either a doPost() or (rarely) a doGet() method. 3) Given what was submitted via the form, work is performed in the servlet. 4) When the servlet work is done and depending on the result (success 1, ..., success n / error 1, ..., error n), the servlet redirects towards the next JSP using the method sendRedirect(). Is there a temporary redirect response to the client in that case? Is this behavior documented somewhere? I could totally benefit from a good documentation... Best regards. Hi, Léa- You can find information about HttpServletResponse and PageContext in the Java Servlet and JavaServer Pages specifications which are available on the Oracle web site. JavaDocs are also available online. Be sure to reference the appropriate versions of the specs and JavaDocs for your application. Links to copies of the JavaDocs are available on the Tomcat documentation pages: Tomcat 7 - https://tomcat.apache.org/tomcat-7.0-doc/index.html Tomcat 8 - https://tomcat.apache.org/tomcat-8.0-doc/index.html The links are labeled Servlet JavaDocs and JSP 2.x JavaDocs in the Reference section on the left. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 11/2/14 10:07 AM, Léa Massiot wrote: Hello Mark, Chris and Terence. Thank you for your answers. After reading them and observing a few things I realized that my problem is not exactly the one I described at first. Christopher Schultz-2 wrote The Referer is going to be the URL that was showing in the web browser when the user clicked on the Submit button. This is right. I hadn't noticed it but the URL which is showing is NOT https://host/webapp/example1.jsp. Instead, it is https://host/webapp/do_example. So, what I was describing as abnormal in my first post is actually normal. Exactly. So the problem is coming from elsewhere... Before I tried to make the webapp work with HTTPS, I was always using calls like these: -- response.sendRedirect(example1.jsp); When sending redirects, you probably always want to: 1. Run the URL through response.encodeRedirectURL 2. Use a URL that starts with /, which is easiest by doing this: String url = response.encodeRedirectURL(request.getContextPath() + /example1.jsp)); response.sendRedirect(url); -- Last week, I replaced all these calls with these new ones: -- requestDispatcher = getServletContext().getRequestDispatcher(/example1.jsp); requestDispatcher.forward(request, response); -- (with the appropriate JSP of course). I made that change because sendRedirect() didn't work with HTTPS. Redirects definitely work with HTTPS. You must be doing something wrong. Perhaps a configuration mistake with a port number or something like that. I didn't mention this before because I thought it was solving this other problem. Instead, it provokes new ones. Yup. What I actually would like is the webapp to behave like before: showing JSP page names in the URLs bar instead of URL patterns: in a given servlet, I generally have several forward() calls and hence several different .jsp pages to forward to depending on what happens inside the servlet. Having all of them replaced by something like do_example is kind of not what I had planned. It's definitely very problematic. So use redirects. They should work and you should figure out why they aren't working. Put your code back the way you had it, take more data, and post a new question if you need help. So, hum, as I didn't asked it at the time: why can't I go on using sendRedirect() along with HTTPS? If I have to use forward(), is there any way I could make it behave the way I described above? When you use a forward, you will always end up with the URL the client first used as what the client sees. If you want to accept data (e.g. POST) *and* prepare some data for the next screen to be seen, consider a POST-then-redirect scheme: 1. Client POSTs to some URL e.g. /do_example 2. /do_example servlet runs and handles the POST data, then redirect()s to /prepare_view 3. /prepare_view servlet runs and gathers whatever data is appropriate for the next display screen and forward()s to /example1.jsp After all that, the user is looking at the URL /prepare_view instead of /do_example. That way, your referrer for the next POST will be /prepare_view instead of /do_example. Is there another method I could use that would suit my needs? Your only tools to transfer control (other than direct function calls) are forward, redirect, and include. P.S. For the problem I was posting at first, as I don't really need to rely on the referer request header, I can instead, set a session attribute in each JSP. In example1.jsp for instance: c:set var=sessAtt value=example1.jsp scope=session/c:set When in the doPost() method of the servlet, I'll know which JSP form what submitted... What if the user hits the BACK button and looks at a previous page, then re-submits that old page? Your server thinks that the source page was example1.jsp but the client actually posted example0.jsp or something else... Web application workflow management is non-trivial. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUV6CAAAoJEBzwKT+lPKRY9zcQAIpXKkNLAq/TVtm9EiRkDHQs boOAcbNluN0D9wK+V94aQTRF1iSFblpaNv6Tr/mmE3hM5c2tuUAxlq3tNAKz9zyn ltzS8w87Zu7zad4i/kZZXKo3IpmpWz8NkWORlHwF4yQQUC/IhtYBxB7nq+7nVfDG aSdKa77rBE6DHklBYutvjdDc2HeYx2B4IgzbYuPGBPEqMKASfhIoxRp51B/lwjEF Zs4TTuiL4SziP/luFBV/GK5kFiPMsEyZhr3YmOi23z44doIgvet89nwOr6im8OEf eFMIyBhos55A3Yc6NEREhyJSBbHbBHIV0cmXxS0qWrsMcj6BEn/Dl6tTyTKyWt1M
Re: From HTTP to HTTPS request.getHeader(referer)
Hi, thank you for your answer. On 2014-11-03 4:34 PM, Christopher Schultz wrote: Redirects definitely work with HTTPS. You must be doing something wrong. Perhaps a configuration mistake with a port number or something like that. My configuration in Tomcat 7.0.55 server.xml is: ( - basically it is the same as the one packaged in the Tomcat distribution, I only changed the connectors ; - I removed all the comments and I'm testing on localhost for this config. ) - ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina Connector port=443 keystoreFile=where/the/ssl/keystore/is/kstore.txt keystorePass=example SSLEnabled=true acceptCount=100 clientAuth=false disableUploadTimeout=true enableLookups=false maxThreads=25 protocol=org.apache.coyote.http11.Http11NioProtocol scheme=https secure=true sslProtocol=TLS / Connector port=80 enableLookups=false redirectPort=443/ Connector port=8009 protocol=AJP/1.3 redirectPort=443 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / /Host /Engine /Service /Server - As for the webapp I would like to HTTPS serve, I only added what follows to its web.xml: - security-constraint web-resource-collection web-resource-namesecuredapp/web-resource-name url-pattern/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint - Is there something wrong or missing? On 2014-11-03 4:34 PM, Christopher Schultz wrote: So use redirects. They should work and you should figure out why they aren't working. Put your code back the way you had it, take more data, and post a new question if you need help. Ok. Thank you. I restored the sendRedirect() calls I was making at first. I proceeded like I described in my last post: passing complete URLs to the sendRedirect() methods (ex. sendRedirect(https://host/webapp/example.jsp;);). As a reminder, before, I used to pass only the JSP page name as an argument to the sendRedirect() method (ex. sendRedirect(example.jsp);). It looks like that the webapp is now working nicely. I noticed your comment about encodeRedirectURL(). Thanks for mentioning it. When you use a forward, you will always end up with the URL the client first used as what the client sees. If you want to accept data (e.g. POST) *and* prepare some data for the next screen to be seen, consider a POST-then-redirect scheme: 1. Client POSTs to some URL e.g. /do_example 2. /do_example servlet runs and handles the POST data, then redirect()s to /prepare_view 3. /prepare_view servlet runs and gathers whatever data is appropriate for the next display screen and forward()s to /example1.jsp After all that, the user is looking at the URL /prepare_view instead of /do_example. That way, your referrer for the next POST will be /prepare_view instead of /do_example. Thank you. It's interesting. What if the user hits the BACK button and looks at a previous page, then re-submits that old page? Your server thinks that the source page was example1.jsp but the client actually posted example0.jsp or something else... Web application workflow management is non-trivial. Yes, it's tricky. Best
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 11/2/14 12:34 PM, Léa Massiot wrote: Hi again. It looks like sendRedirect() is working if I pass it a HTTPS URL as an argument: - String s_prov = request.getScheme() + :// + request.getServerName() + request.getContextPath() + / + example1.jsp; response.sendRedirect(s_prov); - Nota: in my case, request.getScheme() is equal to https. I think I'm going back to sendRedirect()... Snif :'/, it's a lot of matches to replace back (from forward() to sendRedirect())... If you want to switch protocols, then you will have to build the entire URL including the protocol. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUV9YnAAoJEBzwKT+lPKRY6IIP/iM8zeEPhqVKX69XpLDm/7kF SFegFsT2dCQIXA1UhhS6soW7T/7pC92iBFXxJZ6quYG3wHx+mmY5tarb+jpShNo7 FhO+0pKwhV2cixSbXV1mISaheDDfx1PIA7CBRyL9LtA2cioLAxJKdIaMgRQYN2cd FEjqRhpHWKQXYT1CmHNz80FcArVCKMy3UnXMUZbe/XOpNmHRCemS/pAFAtaHm7EV hiej35ztAAUJm5UGq0VhAL61of3ij1sHFthbH4lupc11HWIOqz+pl9KnByYmbIBf ZOJM8Ydma2/41BurVs/vrunqHRI4kNTi475I+xkjt/nYLXuStqsb3D0t7qKtdfkl R02jPFEq76MSvUoe2h73awOfPzddSeMDpwt+ld9BMltOwtsFdqNC6dXXQHB5O4yM y4ov0EIOK0WLgqqhebMquQ1JgIu8+6C3FW7z8HWIRCgkUUl6MaiYJQNTCAIiVYyI a0yKafVBk2nPCWNf2TxOy+yi4AT2SYnCpEsac9wCpracS/cfF7A3N/iJC5bkW+hS s91Y5O7E+p+iD46mT0i3BsiB0V7cVlDWd5I/I0P/dRB7dDUcxKIgnqMAWDGyswxe AU8DNTsWwYSpX51Awq0WkSmInbIgPRRZ8iuY4t7vy5zmB8gHV52zglbH8wsGvnQF BstMynBcam41fi62FgTW =9dkF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
On 11/2/2014 11:34 AM, Léa Massiot wrote: Hi again. It looks like sendRedirect() is working if I pass it a HTTPS URL as an argument: - String s_prov = request.getScheme() + :// + request.getServerName() + request.getContextPath() + / + example1.jsp; response.sendRedirect(s_prov); - Nota: in my case, request.getScheme() is equal to https. I think I'm going back to sendRedirect()... Snif :'/, it's a lot of matches to replace back (from forward() to sendRedirect())... Best regards. Hi, Léa- I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
Hello Mark, Chris and Terence. Thank you for your answers. After reading them and observing a few things I realized that my problem is not exactly the one I described at first. Christopher Schultz-2 wrote The Referer is going to be the URL that was showing in the web browser when the user clicked on the Submit button. This is right. I hadn't noticed it but the URL which is showing is NOT https://host/webapp/example1.jsp. Instead, it is https://host/webapp/do_example. So, what I was describing as abnormal in my first post is actually normal. So the problem is coming from elsewhere... Before I tried to make the webapp work with HTTPS, I was always using calls like these: -- response.sendRedirect(example1.jsp); -- Last week, I replaced all these calls with these new ones: -- requestDispatcher = getServletContext().getRequestDispatcher(/example1.jsp); requestDispatcher.forward(request, response); -- (with the appropriate JSP of course). I made that change because sendRedirect() didn't work with HTTPS. I didn't mention this before because I thought it was solving this other problem. Instead, it provokes new ones. What I actually would like is the webapp to behave like before: showing JSP page names in the URLs bar instead of URL patterns: in a given servlet, I generally have several forward() calls and hence several different .jsp pages to forward to depending on what happens inside the servlet. Having all of them replaced by something like do_example is kind of not what I had planned. It's definitely very problematic. So, hum, as I didn't asked it at the time: why can't I go on using sendRedirect() along with HTTPS? If I have to use forward(), is there any way I could make it behave the way I described above? Is there another method I could use that would suit my needs? Best regards. P.S. For the problem I was posting at first, as I don't really need to rely on the referer request header, I can instead, set a session attribute in each JSP. In example1.jsp for instance: c:set var=sessAtt value=example1.jsp scope=session/c:set When in the doPost() method of the servlet, I'll know which JSP form what submitted... -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782p5024848.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
Léa Massiot wrote Before I tried to make the webapp work with HTTPS, I was always using calls like these: -- response.sendRedirect(example1.jsp); -- Last week, I replaced all these calls with these new ones: -- requestDispatcher = getServletContext().getRequestDispatcher(/example1.jsp); requestDispatcher.forward(request, response); -- (with the appropriate JSP of course). I made that change because sendRedirect() didn't work with HTTPS. I didn't mention this before because I thought it was solving this other problem. Just a precision: if I use sendRedirect(), the error I get is: -- Nov 02, 2014 4:27:25 PM org.apache.coyote.http11.AbstractHttp11Processor process INFO: Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. -- -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782p5024849.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
Hi again. It looks like sendRedirect() is working if I pass it a HTTPS URL as an argument: - String s_prov = request.getScheme() + :// + request.getServerName() + request.getContextPath() + / + example1.jsp; response.sendRedirect(s_prov); - Nota: in my case, request.getScheme() is equal to https. I think I'm going back to sendRedirect()... Snif :'/, it's a lot of matches to replace back (from forward() to sendRedirect())... Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782p5024851.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
On 10/31/2014 11:18 AM, Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2014 5:06 AM, Léa Massiot wrote: Hello and thank you for reading my post. I'm trying to make a webapp work with HTTPS. It was working properly with HTTP. Below is the problem I have. Inside a servlet, in its doPost() method, to check whether the incoming JSP is example1.jsp or example2.jsp, I am using the following piece of code: --- s_referer = request.getHeader(referer); if(s_referer.contains(example1.jsp) == true) { b_jspReferer1 = true; } if(s_referer.contains(example2.jsp) == true) { b_jspReferer2 = true; } --- In example1.jsp and example2.jsp there is a form element which action attribute is set to do_example: --- form method=post action=do_example [...] /form --- Now that I'm using HTTPS, s_referer is always equal to do_example in the servlet. Before, it used to be either example1.jsp in case the incoming JSP was example1.jsp and example2.jsp in case the incoming JSP was example2.jsp. I don't know how to correct my code to be able to discriminate between the two JSPs. Can you please help me? I apologize in advance for the barbaric expression incoming JSP. I hope my point is understandable despite unfortunate expression. Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782.html Sent from the Tomcat - User mailing list archive at Nabble.com. Times the referer will be empty: 1. entered the site URL in browser address bar itself. 2. visited the site by a browser-maintained bookmark. 3. visited the site as first page in the window/tab. 4. switched from a https URL to a http URL. 5. switched from a https URL to a different https URL. 6. has security software installed (antivirus/firewall/etc) which strips the referrer from all requests. 7. is behind a proxy which strips the referrer from all requests. 8. visited the site programmatically (like, curl) without setting the referrer header (searchbots!). Have you looked in various tools on the browser (developer tools on Chrome, Tamper on Firefox, Fiddler on IE) to see if the referer is being set? . . . just my two cents /mde/ Hi, Léa- Rather than relying on REFERER, you might consider using different action attributes in example1.jsp and example2.jsp. The targets could be minimal servlets that set a parameter and forward to do_example. Another approach would be to use hidden input elements in your forms (e.g. input type=hidden name=formId value=1). -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Terence, On 11/1/14 3:44 PM, Terence M. Bandoian wrote: On 10/31/2014 11:18 AM, Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2014 5:06 AM, Léa Massiot wrote: Hello and thank you for reading my post. I'm trying to make a webapp work with HTTPS. It was working properly with HTTP. Below is the problem I have. Inside a servlet, in its doPost() method, to check whether the incoming JSP is example1.jsp or example2.jsp, I am using the following piece of code: --- s_referer = request.getHeader(referer); if(s_referer.contains(example1.jsp) == true) { b_jspReferer1 = true; } if(s_referer.contains(example2.jsp) == true) { b_jspReferer2 = true; } --- In example1.jsp and example2.jsp there is a form element which action attribute is set to do_example: --- form method=post action=do_example [...] /form --- Now that I'm using HTTPS, s_referer is always equal to do_example in the servlet. Before, it used to be either example1.jsp in case the incoming JSP was example1.jsp and example2.jsp in case the incoming JSP was example2.jsp. I don't know how to correct my code to be able to discriminate between the two JSPs. Can you please help me? I apologize in advance for the barbaric expression incoming JSP. I hope my point is understandable despite unfortunate expression. Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782.html Sent from the Tomcat - User mailing list archive at Nabble.com. Times the referer will be empty: 1. entered the site URL in browser address bar itself. 2. visited the site by a browser-maintained bookmark. 3. visited the site as first page in the window/tab. 4. switched from a https URL to a http URL. 5. switched from a https URL to a different https URL. 6. has security software installed (antivirus/firewall/etc) which strips the referrer from all requests. 7. is behind a proxy which strips the referrer from all requests. 8. visited the site programmatically (like, curl) without setting the referrer header (searchbots!). Have you looked in various tools on the browser (developer tools on Chrome, Tamper on Firefox, Fiddler on IE) to see if the referer is being set? . . . just my two cents /mde/ Hi, Léa- Rather than relying on REFERER, you might consider using different action attributes in example1.jsp and example2.jsp. The targets could be minimal servlets that set a parameter and forward to do_example. Another approach would be to use hidden input elements in your forms (e.g. input type=hidden name=formId value=1). +1 The Referer header is not reliable for anything. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUVWo/AAoJEBzwKT+lPKRYkuMP/0xNsWyEd8HwUO+GpzI9e5PE YIHnWp9cp0zDvHnGTYwug5+mavcTDwpCoiGgGusd0Y+UUorz25hyx6AyAlGIcnNc 7aoYDe4tQHkclGiICGB+Ry3z/YO98P8bxwpMbLJEUxhVSLG7fRI6Viix8jfE9/74 8ssb3dr1yFhd2ATOxMfx5Pd23KTAC624JeSl39pWLpG20pvP29cJIk8aBoLbsKoz w7yvkXZJGFBaEC4uRZ6jGGyGPYtxyt+oLfRO1MclPnEXzKTw9Wuck5uJnixWaPVo 3BcBq2AN7QWInZI4LmxCTf5I4qwOUK/vyBlXWez7dVdCiinJkNQ5Fu2kBGCpIu4d 7R9zlrE7uhcuPCFgi3lKrWk8SxpIxrpqfwN1P/SuHcneRY4uZZiKZdxDQcLOBpvi olBdaldiu8XwXM9N3gSixI4W98NIhFQUtwgmLE//kkfILoo4oqzM5op81xZFWoxC PI8UJhwwj14I83NZSHTyT1n1jVFpuEDiygRhXV4A1dklvdC6spH8STodgK0guFlD /kDSPvgV0/AhThL7ja/iuEYOG7T1E5rYT3pA4YfbQn65TBuqmsabxxLt4kADMq+m ADErQmkhJSPR8uM3dJy9ndy137UXFwi+b5R2iT7IuYgMB1TK3EPhQn6JMxtzlNxG F/Y5OrX6lsbFVT4Uze1M =g+8Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2014 5:06 AM, Léa Massiot wrote: Hello and thank you for reading my post. I'm trying to make a webapp work with HTTPS. It was working properly with HTTP. Below is the problem I have. Inside a servlet, in its doPost() method, to check whether the incoming JSP is example1.jsp or example2.jsp, I am using the following piece of code: --- s_referer = request.getHeader(referer); if(s_referer.contains(example1.jsp) == true) { b_jspReferer1 = true; } if(s_referer.contains(example2.jsp) == true) { b_jspReferer2 = true; } --- In example1.jsp and example2.jsp there is a form element which action attribute is set to do_example: --- form method=post action=do_example [...] /form --- Now that I'm using HTTPS, s_referer is always equal to do_example in the servlet. Before, it used to be either example1.jsp in case the incoming JSP was example1.jsp and example2.jsp in case the incoming JSP was example2.jsp. I don't know how to correct my code to be able to discriminate between the two JSPs. Can you please help me? I apologize in advance for the barbaric expression incoming JSP. I hope my point is understandable despite unfortunate expression. Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782.html Sent from the Tomcat - User mailing list archive at Nabble.com. Times the referer will be empty: 1. entered the site URL in browser address bar itself. 2. visited the site by a browser-maintained bookmark. 3. visited the site as first page in the window/tab. 4. switched from a https URL to a http URL. 5. switched from a https URL to a different https URL. 6. has security software installed (antivirus/firewall/etc) which strips the referrer from all requests. 7. is behind a proxy which strips the referrer from all requests. 8. visited the site programmatically (like, curl) without setting the referrer header (searchbots!). Have you looked in various tools on the browser (developer tools on Chrome, Tamper on Firefox, Fiddler on IE) to see if the referer is being set? . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUU7ZlAAoJEEFGbsYNeTwtqbEH/RkgyGagCetRJXRf1rNRwF9x o66i7Ghq2kdfOV8bMqU3jlWEQ7NaRZI6l2aOqkbgsRQBJQqopOn2IakV3EiIdzg3 DoeJmXypucroKAJPKlkUJoI/b6wv8pftjIwaOoqulKcICs5EFA+x+MQPKAOD6Xrp ystXeAy+FD5ChxkAPXzzQQr7BMvUYJptZfOv++s5meS6uAK+u3jpZq5OG0CCLWer K2V15WwswEd2GVZE+ohAnxYkzuheQbxIsTZ+eRwEIl+kiEKLCTruohTqS7fGHOtb TcSxMJvZEQi9Y8B24V6xEbYaWLLwPvk8B2qQ1Uuxwu50ZA4nilUa2wd74jw1zVo= =NOdV -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 10/31/14 8:06 AM, Léa Massiot wrote: Hello and thank you for reading my post. I'm trying to make a webapp work with HTTPS. It was working properly with HTTP. Below is the problem I have. Inside a servlet, in its doPost() method, to check whether the incoming JSP is example1.jsp or example2.jsp, I am using the following piece of code: --- s_referer = request.getHeader(referer); if(s_referer.contains(example1.jsp) == true) Note that true == true is always true and true == false is always false. { b_jspReferer1 = true; } if(s_referer.contains(example2.jsp) == true) { b_jspReferer2 = true; } What is the referrer contains both example1.jsp *and* example2.jsp? --- In example1.jsp and example2.jsp there is a form element which action attribute is set to do_example: --- form method=post action=do_example [...] /form --- Now that I'm using HTTPS, s_referer is always equal to do_example in the servlet. That's weird. Does do_example do an internal forward to example(1|2).jsp for redisplay? If the browser doesn't want to send the Referer header, it won't send one... it's not going to send something bogus. Before, it used to be either example1.jsp in case the incoming JSP was example1.jsp and example2.jsp in case the incoming JSP was example2.jsp. I don't know how to correct my code to be able to discriminate between the two JSPs. Can you please help me? I apologize in advance for the barbaric expression incoming JSP. I hope my point is understandable despite unfortunate expression. The Referer is going to be the URL that was showing in the web browser when the user clicked on the Submit button. If do_example forwards to example1.jsp (instead of performing a redirect), then the browser thinks that the current page is do_example and you'll get that in your Referer header. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUU+KZAAoJEBzwKT+lPKRYtFAQALwANlt5SQJNdeNOBhdw1rd+ bmzpsLoKUYER29dl6xFlfJogS2fu/Wym1EQI1E3+wBWSc3L9VwXUx+qcCSEwfBQ9 aP5AiIp6WoVXw8l1f8vxgZ5iuLqawrMNs3WvypTAS+VCcAk+hx6G83auX/PriVIR HsnUbmcXISiKwbe2BUB5QKICNeWbXacifE8NPDQvpUGtak+xcWf7kolNUWbl/9Gs bSUUEVINkerBTeHisJnTRoQ7sN7fFKZ1ZouDgIh6uTkvKtCjN6EJhR6/sgkFB+cC T92TyaqRtWxJD+gZOCUWY7IJbPgxu04ASLexS796WHRggRr+k31YWOZDIBz1BS0p dkz42wavfj15TPAiZ07NsWxU3hlFl66xpv1EaLWexK2Q7Fqdiy3oVobnHsoUIsa9 gotOV91tATzK9JXWIX/AaALyGvqMXYJAzbRuOnAEEJHES3IJDKdim849zHfFKajJ JvnEFf3gt1A+tWEwussyxVAbWXir+guwTp9IidegXhKNvPmNj1sjiJk/cciVTc54 ZKypluktYedERfJcld/tycaKJY9NFdEHhm+1rv0tV8cPwenlg/qsxQpgUgESksc0 vNOgATWMlPNZLzoLstwigrgHD5d+Non2O+bFl7lUYeFYXKz6jjq4X0yfMvRPiTHL z6TgpoBFrXbfjCAUgQ+x =rl+Q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org