PDA

View Full Version : html text boxes



herWter
12-05-2008, 02:46 PM
One thing that has always bugged me. How exactly do text boxes on websites get the information typed in back to the server without the use of scripts? It that even possible?

Dino
12-05-2008, 03:11 PM
Scripts can be used, but they are at the server.

The submit button, or a submit event (Javascript), in HTML. The browser is doing it. It runs with a GET or POST request to a (usually) CGI script or program at the server.

herWter
12-05-2008, 03:31 PM
So what your saying is the browser sends the data back in a packet regardless of whether or not you use script?

CornedBee
12-05-2008, 03:43 PM
Yes. Forms are older than script.

herWter
12-05-2008, 04:03 PM
Okay. I just have one last question. I was reading an HTML tutorial on W3 and they said that when the submit button is pressed, a file is sent back to the server containing the input. They show that the file is sent back with the extension .asp. Is this so the server will treat them as an ASP script file? And if you're not using a script, what extension would you use?

Dino
12-05-2008, 04:18 PM
"asp" stands for Active Server Pages. And, that's not how it works. ASP is one framework for web sites to use. Another is .jsp, Java Server Pages. And, there are others.

It's not a file, per se, that is sent with a submit button, but "form data", which is just a bunch of parms passed back to the server. A "buffer", if you will.

A file would only be sent back if you were prompted to upload a file (and again, ir would not necessarily have an ".asp" extension. A web site serving up a page to a visitor would have an extension of .asp, if and only if they were using the ASP framework.

herWter
12-05-2008, 04:33 PM
I get it a little bit more now. I misread this line from W3 schools:

When the user clicks on the "Submit" button, the content of the form is sent to the server. The form's action attribute defines the name of the file to send the content to. The file defined in the action attribute usually does something with the received input.

I thought the second sentence meant that a physical file containing the form was sent, but the form data was sent to a file.

CornedBee
12-05-2008, 04:55 PM
And that's still incorrect, because an URL doesn't have to correspond to a file. On the HTTP level, the server receives something like this from the client:


POST url-from-action HTTP/1.1
Host: host-from-action
...
form data follows here
How the server interprets it is really completely up to the server.

herWter
12-05-2008, 05:07 PM
Wow I'm lost. I'd hate to ask anymore nonsense questions so is there any kind of tutorial or book that would teach something like this?

Dino
12-05-2008, 05:14 PM
When I started learning about CGI scripts is when it clicked for me. CGI scripts (and other things like them), more or less, tie the user and the web server together.

Hunt for terms CGI, GET and POST. There are other ways than "forms" to interact with a server, but once you get forms, the rest will follow (in concept if nothing else).

CornedBee
12-05-2008, 05:19 PM
Hum ... something on networking, I guess. "Distributed Systems" by Tanenbaum provides a compact but very decent introduction to how the web works, but it's really a book about distributed systems, so it looks at the larger image and specific problems, not specific technologies. Most server-side scripting books (on PHP, JSP, ASP, Ruby on Rails, and so on) give introductions to how the web works, too.

herWter
12-05-2008, 07:29 PM
Thanks for all your help you guys.

jwenting
12-06-2008, 01:34 AM
The form data is sent as part of the http request, simply as a series of strings of text (possibly encrypted or encoded in some form, for example when you use https instead of http) as key-value pairs.
Depending on whether you're using a post or get request, that data is sent as part of the URL (get request, generating URL parameters like the t=109979 for this thread) or encoded into the request headers (post request).
No file is generated anywhere (though the server could in theory cache the request until it can be processed if it's very busy, which could result in a temp-file somewhere, but that's not part of the request-response cycle but rather an implementation detail).