Quick Question, Please Help...

[Dodger]

Hey All,

How do I get rid of the querystring of a URL?

eg:
===
Intead of www.mysite.com/default.asp?name=dodger&age=1

Rather just www.mysite.com/registered/ (or similar)

Any Ideas?

Thanks.

[monte96]

You need to store the information somehow. You can use cookies or session variables or pass it in form data from page to page. But you have to somehow know that the person is a valid user in order to stop using querystrings.

[Dodger]

Thanks,

What are the disadvantages of using the session object? (if any)

And why don't more sites store querystring info in the session object, in order to shorten url strings?

[monte96]

Querystrings do have size limitations. Most sites don't bother to shorten the size because the data does not need to be secure. Candidates for a Session object variable would be a userID. But even that can be stored on a client computer using cookies and read in on each page.

The problem with the session object is:

1) It uses server resources. This may seem insignificant at first, but suppose you have 1000 connections being handled at the same time?

2) It prevents an application from scaling. The session object is local to the server you are connected to. If you are using load balancing across multiple servers, the session object variable will only be in scope if the user happens to get the same server twice.

It depends on the scale of your application now and in the future as to whether or not to use session object variables.

One thing you never want to do is put objects in the session object. While you can, this invokes problem #1 big time. If you for instance, put a connection object into a session object variable. That connection object will be active and using memory until the user logs off (lets face it, how many of us actually log off versus just moving to a different site) or the session times out. Multiply that memory usage by the number of concurrent users and you have a server resource issue.

[Sastraxi]

Set Form Action to "POST". This'll send it through the HTTP header, although I'm assuming you already know this...

So why am I posting...

[Dodger]

Thanks Guys.

So where do you think I should store variables then?

I don't really like the idea of cookies, because of the fact that not all users have them enabled, and as you say, using the session object can be very hard on the server. And ofcourse, the whole purpose of this post was to avoid using the querystring...

Ahh! I hate computers!...

Are there any other methods?

Can't you just submit the form values to the asp script and have it query the db and authenticate?...no?...ok....

Thanks.

[CiberTHuG]

Well, you've just run into a conceptual problem that... well... you've just realized that man is re-inventing the wheel.

Okay...

In the early days you would sit down at your stand alone computer and connect to the server (mainframe) via a telnet type application (rlogin/TN3270). You would work with the application on the server as a user.

Then came the age of stupid, single user machines running rampant and plaguing peoples minds with the notion that machines should be single user.

Someone built the web to share information, it was not conceived as a medium to run a completely interactive application. But someone figured, why not? It does have its advantages, the graphic front end is handled by the client machine, not the server machine. That reduces the server's load. But there is not a live connection, it is back and forth in posts.

What you need is a technology that we've had around for a long time.

You can telnet into a Unix/Linux box and redirect the display to your local machine. Then you can have your silly GUI and run a program on the remote machine.

This does require more server resources and bandwidth than the web solution, but it offers security (SSH) and provides you with a real, live connection.

Aside from that...

Create a Java application in your web page. That application can connect to a port on the server and keep a live connection open. The client machine does the graphic work and runs the program, the server machine just handles the occasional communication with the Java client.

I could start bitching now, but I won't.

[monte96]

CiberThug... lay off the expresso dude.. lol

Dodger: It depends on when you need the data and where you collect it. If you are getting it from a form and then simply passing it to the next page only, you can just set the method on your form on page 1 to POST instead of GET. If this is data you are going to need throughout your application, store it in a session object on the 2nd page.

I'd need to know a little more specifics on what your doing to be able to give you a better answer as to which road to take.

Problem with cookies is, if someone is paranoid enough to turn them off, they probably also turned off memory cookies, so that will kill being able to use the session object. The session object sets a temporary memory cookie on the client browser that holds the session id of the user so the server knows who is who when receiving requests. If it can't set that temp. cookie, the server can't create a session for the user.

[Dodger]

Thanks Guys,

I'll post again when I am ready to tackle the problem.
(I'm just looking ahead as usual...)