If you've ever used an ssl accelerator with a webapp then maybe you've come accross this problem where your application is effectively incapable of determining which requests are secure versus insecure.

The Problem: When using some form of proxied solution for doing ssl transactions (an ssl accelerator, ssl proxy, etc) the http request that is processed by your application server is unaware of whether or not the original request was processed by your ssl handler. If an application cannot determine which requests are secure versus insecure then it cannot handle scheme enforcement and scheme switching for things like secure logins and registrations. Example ...

  request -> https://mysite/index.jsp (ssl handler) -> http://mysite1.server:8080/index.jsp (app server)

This is a very common scenerio, where there is a proxy setup to handle ssl requests before they get to an application server because the proxy can do ssl handshaking much faster than an app server. The problem that arises in this scenerio is that the app server gets the request from the proxy and does not know if the request was originally over ssl or not. More specifically in a Java webapp this means that the value of request.isSecure() will always be "false" because the application server sees the request as a simple http request. This is a problem if your application tries to ensure security for any of its resources.

Possible Solutions: Unfortunately there doesn't seem to be a fix-all solution to this problem, at least not as far as I have seen. The solution is largely dependent on what application server is being used, how the ssl proxy is setup, and how your application is trying to use it's https vs. http protocol switching.

Tomcat offers a fairly easy way to tackle this problem by allowing users to manually specify that all requests on a given connector are secure vs. insecure as well as setting the scheme to https vs. http. Using this approach you simply configure tomcat to have 2 connectors running on different ports, 1 for http insecure connections, the other for https secure connections. For the https secure connector you just need to set the appropriate properties ...

   <Connector port="8080" scheme="http" secure="false" />

   <Connector port="8043" scheme="https" secure="true" />

Then just setup your proxy to forward insecure requests to tomcat port 8080 and forward ssl handled requests to tomcat port 8043.

If you aren't using tomcat or don't want multiple connectors then an alternative is to try using a custom http header. Often times it's not too difficult to have your proxy set a custom http header for requests that were handled over ssl and if so then all you need to do is enable your application to be aware of that custom header. The easiest way to do that is to define a simple class like MyRequestWrapper which overloads the servlet request.isSecure() method to inspect the request for your custom header. Then use a Filter to wrap the incoming request in your MyRequestWrapper.

I'm sure there are many other alternative ways to tackle this problem, but these two solutions should work for quick a few situations.

A cool article about design ... Data First vs. Structure First

I've gotten into this discussion with a friend of mine several times and strangely I'm still not exactly sure of my position on the topic. My buddy works on some very media centric sites which deliver on demand videos, etc, and so he uses dhtml a lot to make the interface faster and more interactive. My background is much more simple and geared toward the server side because most sites I work on don't have any real need for fancy bells and whistles that require dhtml. He tries to convince me that dhtml is the wave of the future and that everyone is going to be doing it soon. I represent the counter-point that sites which don't *need* dhtml won't use it and that includes most sites on the web.

I totally acknowledge that sites like google maps have used dhtml brilliantly to provide functionality above and beyond what was possible before, however I also believe that applications like google maps are particularly well suited for a more elaborate and interactive experience which dhtml can provide. On most websites I still find that typical uses of dhtml are just fluff and hardly provide a leap in real functionality and in some cases the dhtml just gets in the way and breaks things which probably should have been done in html. It's a tough call, I definitely see some great potential in the combination of dhtml and xml, however I would still be reluctant to rely on it for anything.

I am curious what others think about this. what is dhtml's place on the web? what are other good examples of dhtml being really effective?

Well, phase 1 of the new Roller theme management code is pretty much ready. I'm pretty excited because the coding went pretty much exactly as smooth as I had hoped and usually you leave a bit of extra time assuming that something will go wrong and you'll hit a few bumps in the road. Well the bumps turned out to be mere pebbles this time around and with a little coding this weekend I was able to get things pretty well wrapped up.

I know we are supposed to be on july break now, but I can't help it, I obsess about code. I can't leave code unfinished. Once I get started on a chunk of code there is just no turning back because no matter where I go or what I do my mind will be fixated on coding basically until I've finished the feature or fix. I had planned to have things in a good state when I left for break on Friday, but unfortuantely there were a couple of unexpected hold ups on other projects at the end of the week which altered my schedule and I just couldn't help but finishing things up.

I'll probably commit the new code tomorrow after a few more checks and now that I'm a little ahead of schedule I can look at rolling in some of the theme management v2 features already :D