 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2007What is URL rewriting?
It is said "Cookies and URL rewriting are two common ways to keep track of users between requests." Try to expain URL rewriting? > It is said "Cookies and URL rewriting are two common ways to keep > track of users between requests." > Try to expain URL rewriting? Google is your friend. http://www.google.com/search?q=URL+rewriting Read the wikipedia article, and its external links. >It is said "Cookies and URL rewriting are two common ways to keep >track of users between requests." another common way is to put the user object as attribute into the session object. >> It is said "Cookies and URL rewriting are two common ways to keep >> track of users between requests." > > another common way is to put the user object as attribute into the > session object. Not quite. There is no "the user object" involved, and URL rewriting isn't about attributes, although it does have to do with the session. URL rewriting embeds the session token into the query URL in lieu of storing it in a cookie on the client computer. This token identifies the client session to the server. When the HTML is generated for the client, URLs back to the server are rewritten to include the session token, so if the user selects one of these the server knows to which session to attach the request. kc.wong gave you the good advice on this matter.  SignatureLew >> It is said "Cookies and URL rewriting are two common ways to keep >> track of users between requests." > > another common way is to put the user object as attribute into the > session object. No. The two methods described is used to associate a request with a given session. You can obviously not store that association itself in the session. Arne >The two methods described is used to associate a request with >a given session. in the original post he said "...to keep track of users between requests". That means for me to remember wich user has sent the request. In the enterprise applications I wrote for my company the user information is usually stored as session object. We don't do such things like url rewriting or cookies. But in those applications the user has to login to the application before he can use it. That seems to be the difference... Dirk > Arne Vajh?j wrote: > >The two methods described is used to associate a request with > >a given session. > Dirk wrote: > in the original post he said "...to keep track of users between [quoted text clipped - 4 lines] > user has to login to the application before he can use it. That seems > to be the difference... The session and session objects are stored in the server. Since HTTP is stateless, you need ways to tell which session should be associated with the HTTP requests the server receives. The server generate an unique ID for each session, then send the unique ID to the user agent, so that the user agent can send that ID back on its next request. That's where cookies or URL rewriting comes in - to store the unique ID on client side, and send it back on next request. Since application servers handle the session ID generation and cookie (and URL rewrite if cookie is disabled) automatically, may be it's just that you are not aware of it. Or your application is a thick client. >> >The two methods described is used to associate a request with >> >a given session. [quoted text clipped - 13 lines] > unique ID for each session, then send the unique ID to the user agent, > so that the user agent can send that ID back on its next request. That's true if users log in through an HTML form. If HTTP basic authentication is used instead of an HTML login form, the user name is sent by the browser as part of the HTTP request headers, and it can be used to identify the session. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net URL rewriting is the option when the client browser doesn't accept cookies. The URL's are encoded in the form "URL + ;jsessionid=4545". So, you can do response.encodeURL("/ servlet") to encode your URL's, but this will make effect only if the browser doesn't accept cookies. > kc.wong....@gmail.com writes: > >> Arne Vajh?j wrote: [quoted text clipped - 29 lines] > > - Show quoted text - > If HTTP basic authentication is used instead of an HTML login form, the > user name is sent by the browser as part of the HTTP request headers, and > it can be used to identify the session. Which servlet containers will use that for session identification ? Arne >> If HTTP basic authentication is used instead of an HTML login form, the >> user name is sent by the browser as part of the HTTP request headers, and >> it can be used to identify the session. > > Which servlet containers will use that for session identification ? Irrelevant. The post I responded to claimed that cookies and URL rewriting were the only way to manage sessions. They're not. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net >>> If HTTP basic authentication is used instead of an HTML login form, the >>> user name is sent by the browser as part of the HTTP request headers, and [quoted text clipped - 3 lines] > Irrelevant. The post I responded to claimed that cookies and URL rewriting > were the only way to manage sessions. They're not. They are the only way with existing servlet containers. And given that the servlet specs support session without login and that session based on basic auth would be a mess if two PC's logged in with the same username, then you can be pretty sure that it session based on basic auth will never be an option. Arne >>>> If HTTP basic authentication is used instead of an HTML login form, the >>>> user name is sent by the browser as part of the HTTP request headers, and [quoted text clipped - 5 lines] > > They are the only way with existing servlet containers. Please re-read what I wrote. I said that HTTP auth can be used to identify sessions - that's all. Whether servlets support that option or not isn't relevant; the fact remains that it's possible in general. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net >>>>> If HTTP basic authentication is used instead of an HTML login form, the >>>>> user name is sent by the browser as part of the HTTP request headers, and [quoted text clipped - 7 lines] > sessions - that's all. Whether servlets support that option or not isn't > relevant; the fact remains that it's possible in general. Since this is a Java group ... Arne >>>>>> If HTTP basic authentication is used instead of an HTML login form, the >>>>>> user name is sent by the browser as part of the HTTP request headers, and [quoted text clipped - 9 lines] > > Since this is a Java group ... So what's your point? "Possible in general" includes Java. It's possible to do HTTP auth sessions in Java. You might need to write a new application server to do it, if existing servlet containers don't allow that option. But I didn't say it would be cheap or easy - I said it can be done. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net >> Since this is a Java group ... > > So what's your point? "Possible in general" includes Java. It's possible to > do HTTP auth sessions in Java. You might need to write a new application > server to do it, if existing servlet containers don't allow that option. But > I didn't say it would be cheap or easy - I said it can be done. Considering that Java is Turing complete, this just isn't really meaningful at all. We should probably restrict the discussion to how things can be done in Java with limited cost and effort, limiting ourselves to existing servlet containers and APIs. SignatureKenneth P. Turvey <kt-usenet@squeakydolphin.com> >>> Since this is a Java group ... >> [quoted text clipped - 5 lines] > Considering that Java is Turing complete, this just isn't really > meaningful at all. I'll concede that it's nit-picking, but I don't think it's meaningless. Precision is important in programming, and there is a distinct difference between "it can't be done," and "it'll take some work to adapt an existing servlet container to do it." > We should probably restrict the discussion to how things can be done in > Java with limited cost and effort, limiting ourselves to existing servlet > containers and APIs. I've just reviewed the "what it's for" description that's posted here often, and I don't see any such restriction. Frankly, given the amount of pure drivel being posted in other threads, I think that "we" would be happy to see someone actually talking about Java at all... :-) sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net > Frankly, given the amount of pure drivel being posted in other threads, I > think that "we" would be happy to see someone actually talking about Java > at all... :-) How ironic. SignatureLew >> The two methods described is used to associate a request with >> a given session. [quoted text clipped - 6 lines] > user has to login to the application before he can use it. That seems > to be the difference... You use cookies or URL rewriting. The servlet container handles it for you, but they are still there. Arne > in the original post he said "...to keep track of users between > requests". That means for me to remember wich user has sent the > request. In the enterprise applications I wrote for my company the > user information is usually stored as session object. Are you a consultant? ;-) > We don't do such > things like url rewriting or cookies. If you start an engine you don't do such things like fuel injection, either. You simply turn a key or press a button. But be assured that this still happens. > But in those applications the > user has to login to the application before he can use it. That seems > to be the difference... It only seems to be the difference between a developer for enterprise applications and normal developers. The enterprise developer doesn't seem to be interested into the things under the cover of frameworks being used. And cookies and URL-re- writing are the basic concepts being necessary to have some- thing like a session-object that can be used for something. No pun intended, but that was coming up my mind when reading "In the enterprise applications I wrote..." ;-) Regards, Lothar SignatureLothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! > It only seems to be the difference between a developer for > enterprise applications and normal developers. The enterprise > developer doesn't seem to be interested into the things under > the cover of frameworks being used. And cookies and URL-re- > writing are the basic concepts being necessary to have some- > thing like a session-object that can be used for something. Alas, that is not a difference but an all-too common trait amongst many programmers, that they care not what is really going on in their APIs. This lack of understanding, willful or otherwise, severely hampers the effectiveness and correctness of their work. SignatureLew >> It only seems to be the difference between a developer for >> enterprise applications and normal developers. The enterprise [quoted text clipped - 7 lines] > This lack of understanding, willful or otherwise, severely hampers the > effectiveness and correctness of their work. When required to get the job done, I'll look at anything down to zeros and ones in logic analyzer traces. I only draw the line when an electrical engineer looks at an oscilloscope and says something like "That is not a very good zero.". However, if I looked at everything in that level of detail, I would never get any high level programming done. I think it is VERY important to pick a suitable model for thinking about a given problem, and it is not necessarily the case that a more detailed model is better. Often, I just accept that an API does what it is documented to do, and program accordingly. Patricia > I think it is VERY important to pick a suitable model for thinking about > a given problem, and it is not necessarily the case that a more detailed > model is better. Often, I just accept that an API does what it is > documented to do, and program accordingly. In order to use an API to do "what it is documented to do", you have to understand what it's documented to do. For example, I've worked with people who knew what the API docs for Struts say, but didn't understand the model-view-controller paradigm that is the heart of Struts' structure. I'm not saying you need to use an oscilloscope to see how good your zeros are. I'm saying you have to understand what your APIs are doing. SignatureLew > When required to get the job done, I'll look at anything down to zeros > and ones in logic analyzer traces. I only draw the line when an > electrical engineer looks at an oscilloscope and says something like > "That is not a very good zero.". Sure but if two engineers are starting a discussion about the electrical details of a switch you most likely will not join the discussion with something like "I just press the button to break the circuit. We don't do such things like using a switch". Regards, Lothar SignatureLothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! > It is said "Cookies and URL rewriting are two common ways to keep > track of users between requests." > Try to expain URL rewriting? Instead of storing the session id in a cookie, then it is stored in the URL. Arne Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.