|
|
I'm trying to create a custom HTTP header that will be assigned by a JSP, and then read every time the user clicks on a link. I know you can assign them in JSPs, but I can't find any information or code samples! Help!!!
|
|
|
|
I'm not a JSP programmer, but you mention reading an HTTP header when a user clicks a link--that sounds like javascript, which I do know. You can't access the HTTP Headers with client-side javascript. You can modify cookies which are sent in the HTTP Header to the server, but you can't directly access or modify the HTTP Headers with client-side javascript.
What do you want to actually DO? Maybe we can help you craft a solution.
|
|
|
|
|
|
Hi Troy. Here's what I'm doing. I need to maintain information for what state a user is in (i.e. Mass, New York, etc.). This will determine what content they can see on the site I'm developing. This would be easy if I was using an application server, but I can't for various reasons. I can't use session on the web server to maintain it because there are 3 web servers that are load balanced, and they don't share session information. These things can't be changed. I can't rely on cookies because people can disable them. So, that leaves me with three options:
1. URL rewriting
2. a hidden form variable
3. HTTP header information
Using 1 and 2 will be messy. Option 1 means that every URL will need to have state information appended to it, plus more (there's other info too, but I don't want to confuse the issue). We don't want to have ugly, long URLs so that option is out. Option 2 will require us to write a Javascript function, and every href on the page will have to call that function and pass it a URL in order to POST the hidden form variable to the server. Again, a messy solution, so we can't do it.
That leaves me with only HTTP header variables. The architecture/technology is fixed, which means the content is parsed in Java on the server in a JSP, so I need to know how to set and retrieve a custom HTTP variable. So far I found two different native Java methods that I believe I can use, but there's very little info (mainly a code sample!) that I can find on the web on how to implement them. These are:
getHeaderField()
setRequestProperty()
|
|
|
|
What percentage of web users have cookies disabled? I'd think that would be a very tiny part of your audience -- can you afford to exclude them? If your app detects that they have cookies disabled, you could direct to a page that explains why your site uses cookies.
Sessions use cookies anyway, so even if you weren't using a web server cluster, if you can't depend on cookies, sessions would not be an option.
Unless you use cookieless sessions in which case, you use url re-writing. This seems like your best option, use URL rewriting to only store your own session ID in the url. Store all the data for each session in a database with the session ID as the primary key. On each page submit, you can get the session ID from the URL, then look up the session data in the database.
I like to roll my own sessions anyway to get away from the timeout constraints of the built-in server sessions. I develop a few web-based data-entry type apps where I want the user to log in once in the morning and stay logged in -- standard sessions won't work for me.
|
|
|
|
|
|
If you're using a Java-based web or application server with the native Java session management objects, there are no cookies. Sessions are maintained strictly in memory. The concept of server-side cookies has no bearing on this platform.
As for the number of users who disable cookies, it makes no difference if it's only .001%. The solution I develop has to work for everybody for legal and business reasons without them having to change their settings.
But, I'll take any and all ideas, and I appreciate your comments! :) I've worked with Java, VB, JavaScript, Perl, and most web languages for anywhere from 2-6 years now. In this case, I'm using web servers that can only run Java or CGI languages, and session information must be maintained somehow. With my experience, I've decided that http headers are the only option I have left.
|
|
|
|
|
|
|
|
teflon_jones
Troy Wolf