Report, edit, etc...Posted by cuinhell(ds) on 2005-08-06 at 14:17:04
Hey I have noticed a few things about this site that amazes me of how you guys do it.
Such as if you go to change your profile image then go to an older post it changes that image. How in the world do you do that with html editin?
another thing i have noticed. How can you edit the entire site with out it being down time to time.?
Ok last one
When you say go to your my Controls how do you give every one the access to edit every thing for their self's?
Just wonderin some of these things im pretty sure the codin is long on them so just explain how it works. no html need.
Or is this topic a secruity breached.?
Such as if you go to change your profile image then go to an older post it changes that image. How in the world do you do that with html editin?
another thing i have noticed. How can you edit the entire site with out it being down time to time.?
Ok last one
When you say go to your my Controls how do you give every one the access to edit every thing for their self's?
Just wonderin some of these things im pretty sure the codin is long on them so just explain how it works. no html need.
Or is this topic a secruity breached.?
Report, edit, etc...Posted by Staredit.Net Essence on 2005-08-06 at 15:25:15
Forums don't just use HTML. They use Databases, PHP, CSS and many other things.
If you notice when SEN goes down, it says something about MySQL. That's the database that SEN has. All of our info is stored in MySQL databases.
HTML is for layouts, not all the really heafty stuff
If you notice when SEN goes down, it says something about MySQL. That's the database that SEN has. All of our info is stored in MySQL databases.
HTML is for layouts, not all the really heafty stuff
Report, edit, etc...Posted by warhammer40000 on 2005-08-06 at 15:38:48
They use PHP, too.
Report, edit, etc...Posted by Staredit.Net Essence on 2005-08-06 at 15:52:11
QUOTE(Kellimus @ Aug 6 2005, 12:25 PM)
Forums don't just use HTML. They use Databases, PHP, CSS and many other things.
If you notice when SEN goes down, it says something about MySQL. That's the database that SEN has. All of our info is stored in MySQL databases.
HTML is for layouts, not all the really heafty stuff
[right][snapback]280509[/snapback][/right]
If you notice when SEN goes down, it says something about MySQL. That's the database that SEN has. All of our info is stored in MySQL databases.
HTML is for layouts, not all the really heafty stuff
[right][snapback]280509[/snapback][/right]
Notice the bold and underline.......
Report, edit, etc...Posted by warhammer40000 on 2005-08-06 at 16:03:05
Uh.. you edited that in! And hacked the forums so it didnt say "This post was edited blah blah!"
Report, edit, etc...Posted by DT_Battlekruser on 2005-08-06 at 16:19:29
When you login, Staredit.net sets a cookie to recognize you. It logs a something like 20-digit hex SESSION ID to the database. Then, if you are loading within 15 minutes of your last click and have the cookie that identifies you, it automatically counts you as you. Outside of 15 minutes, the session expires and you have to log in again*.
It then can tell what member you are and display data accordingly. All this is done in PHP and Java, not just HTML.
*If you check "Remeber Me" it auto logs you in if you have the cookie.
It then can tell what member you are and display data accordingly. All this is done in PHP and Java, not just HTML.
*If you check "Remeber Me" it auto logs you in if you have the cookie.
Report, edit, etc...Posted by Tarh on 2005-08-06 at 17:03:00
At first, it may be difficult to grasp the concept of how server-side technologies such as PHP function. To a beginning HTML coder, most of the Internet Protocol still remains a mystery. Most, once done with their WYSIWYG editors and after moving to directly coding HTML, do not understand the basic concepts that allow their code to work. To them, it is simply "code page . . . upload file . . . ooh . . . pretty". If one ever wishes to delve deeper into the realm of server-side scripting, one must learn the Internet Protocol.
This post may be a little deeper into facts then you may be willing to venture at this point, so if you are brave and truly want to know how such technologies function, read on.
The World Wide Web uses several transfer protocols over TCP/IP (sometimes other protocols are used, but rarely). These include HTTP (hyper text transfer protocol) and FTP (file transfer protocol). HTTP was originally designed to transfer files with a Hyper Text Markup (HTM / HTML), but is capable of transferring any file, including non-plain-text files.
The basic idea is that certain computers, named "servers", contain a file on their hard drive in a special location. They also run software that constantly listens on a port (HTTP is usually port 80). When a remote system connects on that port, the server performs actions that eventually return a file (or a code representing the delivery failure).
Since the time that this idea was created, it has evolved greatly. HTTP/1.1 is capable of far more than simply delivering HTM files.
The client, who connects to servers to retrieve information, does so through special software that eventually evolved to be called an "internet browser" (such as Internet Explorer, Firefox, or Opera).
The connection starts with the client. The client connects to the server and sends the request information. The server then performs whatever actions it needs to, and returns data. The client is the one that closes the connection after. The connection is always closed after the final data is sent by the server (with one exception, keep-alive, beyond the scope of this post).
For demonstration purposes on the actual data flow of HTTP, I connected to myself with Firefox 1.0.6 to get "/index.html". When a client connects to a server through Firefox and requests "index.html" from the root directory, the data sent from the client to the server in a form something like this:
The data can be sent in multiple fragments, where it is re-assembled by the server.
As for the format of the message: A message consists of a header, and content. The header and content are separated by either CrLfCrLf or LfLf. A server should be prepared to handle this both ways. You can see that in this message, the content is blank.
The header consists of names and values. Each name means something in the HTTP protocol specifications, and the server is expected to respond based on every one of these names and their values. Names and values are separated by the first colon (":") of the line.
Just as the client sends information, the server responds with it. A request like this, somewhat modified, sent to www.staredit.net would get a response like this:
(The entire HTML source would follow, but that would make the post too long
)
Now that you understand (at least marginally) the HTTP protocol, we may address your question of how the server seems to magically change it's pages. It is quite simple. The files on the server have special coding in them. They use a separate "language" known as PHP (for SEN anyway). When the client requests a page with the extension of .php, the server calls a special function. This reads through the file before sending it, and executes the special language. The language is very close to a true programming language in abilities and access. The server, instead of sending the file as it reads it, follows the instructions in the PHP code, and then removes it. In effect, the client NEVER sees any PHP code in the HTML that it receives. In fact, the code that is received is basically normal HTML coding. The PHP code on sites like SEN allow the pages to be "dynamic", and able to change for each user that visits it.
A "cookie" is a special convention used by web browsers. Web servers can include a header in their HTTP response which instructs the browser to store information. The idea is to have some kind of state in a stateless protocol (HTTP is a stateless protocol because, by default, the server does not maintain the connection nor remember anyone who visits the page). The browser, of course, is free to ignore this instruction, but usually they don't. From that moment on, every time that you visit the website that set the cookie, the data is sent back to the website.
SEN stores a cookie on your computer that allows it to remember your user account everytime you visit. Everytime you visit the website, your browser tells the website the value that it saved on your computer. The value means something to the server, depending on the system that the coders created. In SEN's case, it stores an attachment to your user account. There are actually deeper things going on here called sessions, but that is an advanced concept in many server-side languages.
The server is also free to remember you based on your Internet Protocol Address, which is a special sequence of 4 unsigned short ints (0 - 255) separated by decimal points ("."). The admins, when they "ban you", simply tell their code to send you an error message everytime that the server receives a connection from a user with a banned IP address. Since people can change their IP addresses dynamically, however, this doesn't work very well. That, however, is topic of another discussion.
So, now you know more than you ever wanted to about HTTP, server-side languages, and dynamic content. Now go and brag to your friends .
If you want to learn more about the web, visit http://www.w3schools.com
If you want to learn more about PHP, visit http://www.w3schools.com/php/default.asp
If you want to learn more about SQL, visit http://www.w3schools.com/sql/default.asp
Or, if you want to learn more about the super-dee-duper Microsoft server-side language, visit http://www.w3schools.com/asp/default.asp
Good luck, and happy coding!
P.S. Sorry if I repeated anything previously said (it took a long time to write this out!), or if I made any stupid errors I made writing this.
This post may be a little deeper into facts then you may be willing to venture at this point, so if you are brave and truly want to know how such technologies function, read on.
The World Wide Web uses several transfer protocols over TCP/IP (sometimes other protocols are used, but rarely). These include HTTP (hyper text transfer protocol) and FTP (file transfer protocol). HTTP was originally designed to transfer files with a Hyper Text Markup (HTM / HTML), but is capable of transferring any file, including non-plain-text files.
The basic idea is that certain computers, named "servers", contain a file on their hard drive in a special location. They also run software that constantly listens on a port (HTTP is usually port 80). When a remote system connects on that port, the server performs actions that eventually return a file (or a code representing the delivery failure).
Since the time that this idea was created, it has evolved greatly. HTTP/1.1 is capable of far more than simply delivering HTM files.
The client, who connects to servers to retrieve information, does so through special software that eventually evolved to be called an "internet browser" (such as Internet Explorer, Firefox, or Opera).
The connection starts with the client. The client connects to the server and sends the request information. The server then performs whatever actions it needs to, and returns data. The client is the one that closes the connection after. The connection is always closed after the final data is sent by the server (with one exception, keep-alive, beyond the scope of this post).
For demonstration purposes on the actual data flow of HTTP, I connected to myself with Firefox 1.0.6 to get "/index.html". When a client connects to a server through Firefox and requests "index.html" from the root directory, the data sent from the client to the server in a form something like this:
CODE
GET /index.html HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,en-ca;q=0.3
---------------: ------------
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,en-ca;q=0.3
---------------: ------------
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive
The data can be sent in multiple fragments, where it is re-assembled by the server.
As for the format of the message: A message consists of a header, and content. The header and content are separated by either CrLfCrLf or LfLf. A server should be prepared to handle this both ways. You can see that in this message, the content is blank.
The header consists of names and values. Each name means something in the HTTP protocol specifications, and the server is expected to respond based on every one of these names and their values. Names and values are separated by the first colon (":") of the line.
Just as the client sends information, the server responds with it. A request like this, somewhat modified, sent to www.staredit.net would get a response like this:
CODE
HTTP/1.1 200 OK
Date: Sat, 06 Aug 2005 20:44:19 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.0 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
X-Powered-By: PHP/4.4.0
Set-Cookie: session_id=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; path=/; domain=.staredit.net
Keep-Alive: timeout=1, max=10000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
F971
<!--
The images for the layout were created by Yoshi da Sniper.
The Javascript menu was created by Isolated Purity.
The HTML was by both,
We pwn.
You can look at the source, but theres nothing interestin;)
-->
Date: Sat, 06 Aug 2005 20:44:19 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.0 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
X-Powered-By: PHP/4.4.0
Set-Cookie: session_id=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; path=/; domain=.staredit.net
Keep-Alive: timeout=1, max=10000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
F971
<!--
The images for the layout were created by Yoshi da Sniper.
The Javascript menu was created by Isolated Purity.
The HTML was by both,
We pwn.
You can look at the source, but theres nothing interestin;)
-->
(The entire HTML source would follow, but that would make the post too long
) Now that you understand (at least marginally) the HTTP protocol, we may address your question of how the server seems to magically change it's pages. It is quite simple. The files on the server have special coding in them. They use a separate "language" known as PHP (for SEN anyway). When the client requests a page with the extension of .php, the server calls a special function. This reads through the file before sending it, and executes the special language. The language is very close to a true programming language in abilities and access. The server, instead of sending the file as it reads it, follows the instructions in the PHP code, and then removes it. In effect, the client NEVER sees any PHP code in the HTML that it receives. In fact, the code that is received is basically normal HTML coding. The PHP code on sites like SEN allow the pages to be "dynamic", and able to change for each user that visits it.
A "cookie" is a special convention used by web browsers. Web servers can include a header in their HTTP response which instructs the browser to store information. The idea is to have some kind of state in a stateless protocol (HTTP is a stateless protocol because, by default, the server does not maintain the connection nor remember anyone who visits the page). The browser, of course, is free to ignore this instruction, but usually they don't. From that moment on, every time that you visit the website that set the cookie, the data is sent back to the website.
SEN stores a cookie on your computer that allows it to remember your user account everytime you visit. Everytime you visit the website, your browser tells the website the value that it saved on your computer. The value means something to the server, depending on the system that the coders created. In SEN's case, it stores an attachment to your user account. There are actually deeper things going on here called sessions, but that is an advanced concept in many server-side languages.
The server is also free to remember you based on your Internet Protocol Address, which is a special sequence of 4 unsigned short ints (0 - 255) separated by decimal points ("."). The admins, when they "ban you", simply tell their code to send you an error message everytime that the server receives a connection from a user with a banned IP address. Since people can change their IP addresses dynamically, however, this doesn't work very well. That, however, is topic of another discussion.
So, now you know more than you ever wanted to about HTTP, server-side languages, and dynamic content. Now go and brag to your friends
. If you want to learn more about the web, visit http://www.w3schools.com
If you want to learn more about PHP, visit http://www.w3schools.com/php/default.asp
If you want to learn more about SQL, visit http://www.w3schools.com/sql/default.asp
Or, if you want to learn more about the super-dee-duper Microsoft server-side language, visit http://www.w3schools.com/asp/default.asp
Good luck, and happy coding!
P.S. Sorry if I repeated anything previously said (it took a long time to write this out!), or if I made any stupid errors I made writing this.
Report, edit, etc...Posted by cuinhell(ds) on 2005-08-06 at 17:46:33
omg i learned alot thanks a bunch with such longin replys lol. Thanks you all. Now i understand a little bit more than i did. And thanks for the links im gonna go check into that. Thanks again all. Oh and tarh here ill give you some minerals for the learning lesson
Report, edit, etc...Posted by DT_Battlekruser on 2005-08-06 at 17:56:40
QUOTE(Tarh @ Aug 6 2005, 02:03 PM)
At first, it may be difficult to grasp the concept of how server-side technologies such as PHP function. To a beginning HTML coder, most of the Internet Protocol still remains a mystery. Most, once done with their WYSIWYG editors and after moving to directly coding HTML, do not understand the basic concepts that allow their code to work. To them, it is simply "code page . . . upload file . . . ooh . . . pretty". If one ever wishes to delve deeper into the realm of server-side scripting, one must learn the Internet Protocol.
This post may be a little deeper into facts then you may be willing to venture at this point, so if you are brave and truly want to know how such technologies function, read on.
The World Wide Web uses several transfer protocols over TCP/IP (sometimes other protocols are used, but rarely). These include HTTP (hyper text transfer protocol) and FTP (file transfer protocol). HTTP was originally designed to transfer files with a Hyper Text Markup (HTM / HTML), but is capable of transferring any file, including non-plain-text files.
The basic idea is that certain computers, named "servers", contain a file on their hard drive in a special location. They also run software that constantly listens on a port (HTTP is usually port 80). When a remote system connects on that port, the server performs actions that eventually return a file (or a code representing the delivery failure).
Since the time that this idea was created, it has evolved greatly. HTTP/1.1 is capable of far more than simply delivering HTM files.
The client, who connects to servers to retrieve information, does so through special software that eventually evolved to be called an "internet browser" (such as Internet Explorer, Firefox, or Opera).
The connection starts with the client. The client connects to the server and sends the request information. The server then performs whatever actions it needs to, and returns data. The client is the one that closes the connection after. The connection is always closed after the final data is sent by the server (with one exception, keep-alive, beyond the scope of this post).
For demonstration purposes on the actual data flow of HTTP, I connected to myself with Firefox 1.0.6 to get "/index.html". When a client connects to a server through Firefox and requests "index.html" from the root directory, the data sent from the client to the server in a form something like this:
The data can be sent in multiple fragments, where it is re-assembled by the server.
As for the format of the message: A message consists of a header, and content. The header and content are separated by either CrLfCrLf or LfLf. A server should be prepared to handle this both ways. You can see that in this message, the content is blank.
The header consists of names and values. Each name means something in the HTTP protocol specifications, and the server is expected to respond based on every one of these names and their values. Names and values are separated by the first colon (":") of the line.
Just as the client sends information, the server responds with it. A request like this, somewhat modified, sent to www.staredit.net would get a response like this:
(The entire HTML source would follow, but that would make the post too long )
Now that you understand (at least marginally) the HTTP protocol, we may address your question of how the server seems to magically change it's pages. It is quite simple. The files on the server have special coding in them. They use a separate "language" known as PHP (for SEN anyway). When the client requests a page with the extension of .php, the server calls a special function. This reads through the file before sending it, and executes the special language. The language is very close to a true programming language in abilities and access. The server, instead of sending the file as it reads it, follows the instructions in the PHP code, and then removes it. In effect, the client NEVER sees any PHP code in the HTML that it receives. In fact, the code that is received is basically normal HTML coding. The PHP code on sites like SEN allow the pages to be "dynamic", and able to change for each user that visits it.
A "cookie" is a special convention used by web browsers. Web servers can include a header in their HTTP response which instructs the browser to store information. The idea is to have some kind of state in a stateless protocol (HTTP is a stateless protocol because, by default, the server does not maintain the connection nor remember anyone who visits the page). The browser, of course, is free to ignore this instruction, but usually they don't. From that moment on, every time that you visit the website that set the cookie, the data is sent back to the website.
SEN stores a cookie on your computer that allows it to remember your user account everytime you visit. Everytime you visit the website, your browser tells the website the value that it saved on your computer. The value means something to the server, depending on the system that the coders created. In SEN's case, it stores an attachment to your user account. There are actually deeper things going on here called sessions, but that is an advanced concept in many server-side languages.
The server is also free to remember you based on your Internet Protocol Address, which is a special sequence of 4 unsigned short ints (0 - 255) separated by decimal points ("."). The admins, when they "ban you", simply tell their code to send you an error message everytime that the server receives a connection from a user with a banned IP address. Since people can change their IP addresses dynamically, however, this doesn't work very well. That, however, is topic of another discussion.
So, now you know more than you ever wanted to about HTTP, server-side languages, and dynamic content. Now go and brag to your friends .
If you want to learn more about the web, visit http://www.w3schools.com
If you want to learn more about PHP, visit http://www.w3schools.com/php/default.asp
If you want to learn more about SQL, visit http://www.w3schools.com/sql/default.asp
Or, if you want to learn more about the super-dee-duper Microsoft server-side language, visit http://www.w3schools.com/asp/default.asp
Good luck, and happy coding!
P.S. Sorry if I repeated anything previously said (it took a long time to write this out!), or if I made any stupid errors I made writing this.
[right][snapback]280546[/snapback][/right]
This post may be a little deeper into facts then you may be willing to venture at this point, so if you are brave and truly want to know how such technologies function, read on.
The World Wide Web uses several transfer protocols over TCP/IP (sometimes other protocols are used, but rarely). These include HTTP (hyper text transfer protocol) and FTP (file transfer protocol). HTTP was originally designed to transfer files with a Hyper Text Markup (HTM / HTML), but is capable of transferring any file, including non-plain-text files.
The basic idea is that certain computers, named "servers", contain a file on their hard drive in a special location. They also run software that constantly listens on a port (HTTP is usually port 80). When a remote system connects on that port, the server performs actions that eventually return a file (or a code representing the delivery failure).
Since the time that this idea was created, it has evolved greatly. HTTP/1.1 is capable of far more than simply delivering HTM files.
The client, who connects to servers to retrieve information, does so through special software that eventually evolved to be called an "internet browser" (such as Internet Explorer, Firefox, or Opera).
The connection starts with the client. The client connects to the server and sends the request information. The server then performs whatever actions it needs to, and returns data. The client is the one that closes the connection after. The connection is always closed after the final data is sent by the server (with one exception, keep-alive, beyond the scope of this post).
For demonstration purposes on the actual data flow of HTTP, I connected to myself with Firefox 1.0.6 to get "/index.html". When a client connects to a server through Firefox and requests "index.html" from the root directory, the data sent from the client to the server in a form something like this:
CODE
GET /index.html HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,en-ca;q=0.3
---------------: ------------
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,en-ca;q=0.3
---------------: ------------
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive
The data can be sent in multiple fragments, where it is re-assembled by the server.
As for the format of the message: A message consists of a header, and content. The header and content are separated by either CrLfCrLf or LfLf. A server should be prepared to handle this both ways. You can see that in this message, the content is blank.
The header consists of names and values. Each name means something in the HTTP protocol specifications, and the server is expected to respond based on every one of these names and their values. Names and values are separated by the first colon (":") of the line.
Just as the client sends information, the server responds with it. A request like this, somewhat modified, sent to www.staredit.net would get a response like this:
CODE
HTTP/1.1 200 OK
Date: Sat, 06 Aug 2005 20:44:19 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.0 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
X-Powered-By: PHP/4.4.0
Set-Cookie: session_id=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; path=/; domain=.staredit.net
Keep-Alive: timeout=1, max=10000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
F971
<!--
The images for the layout were created by Yoshi da Sniper.
The Javascript menu was created by Isolated Purity.
The HTML was by both,
We pwn.
You can look at the source, but theres nothing interestin;)
-->
Date: Sat, 06 Aug 2005 20:44:19 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.0 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
X-Powered-By: PHP/4.4.0
Set-Cookie: session_id=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; path=/; domain=.staredit.net
Keep-Alive: timeout=1, max=10000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
F971
<!--
The images for the layout were created by Yoshi da Sniper.
The Javascript menu was created by Isolated Purity.
The HTML was by both,
We pwn.
You can look at the source, but theres nothing interestin;)
-->
(The entire HTML source would follow, but that would make the post too long
) Now that you understand (at least marginally) the HTTP protocol, we may address your question of how the server seems to magically change it's pages. It is quite simple. The files on the server have special coding in them. They use a separate "language" known as PHP (for SEN anyway). When the client requests a page with the extension of .php, the server calls a special function. This reads through the file before sending it, and executes the special language. The language is very close to a true programming language in abilities and access. The server, instead of sending the file as it reads it, follows the instructions in the PHP code, and then removes it. In effect, the client NEVER sees any PHP code in the HTML that it receives. In fact, the code that is received is basically normal HTML coding. The PHP code on sites like SEN allow the pages to be "dynamic", and able to change for each user that visits it.
A "cookie" is a special convention used by web browsers. Web servers can include a header in their HTTP response which instructs the browser to store information. The idea is to have some kind of state in a stateless protocol (HTTP is a stateless protocol because, by default, the server does not maintain the connection nor remember anyone who visits the page). The browser, of course, is free to ignore this instruction, but usually they don't. From that moment on, every time that you visit the website that set the cookie, the data is sent back to the website.
SEN stores a cookie on your computer that allows it to remember your user account everytime you visit. Everytime you visit the website, your browser tells the website the value that it saved on your computer. The value means something to the server, depending on the system that the coders created. In SEN's case, it stores an attachment to your user account. There are actually deeper things going on here called sessions, but that is an advanced concept in many server-side languages.
The server is also free to remember you based on your Internet Protocol Address, which is a special sequence of 4 unsigned short ints (0 - 255) separated by decimal points ("."). The admins, when they "ban you", simply tell their code to send you an error message everytime that the server receives a connection from a user with a banned IP address. Since people can change their IP addresses dynamically, however, this doesn't work very well. That, however, is topic of another discussion.
So, now you know more than you ever wanted to about HTTP, server-side languages, and dynamic content. Now go and brag to your friends
. If you want to learn more about the web, visit http://www.w3schools.com
If you want to learn more about PHP, visit http://www.w3schools.com/php/default.asp
If you want to learn more about SQL, visit http://www.w3schools.com/sql/default.asp
Or, if you want to learn more about the super-dee-duper Microsoft server-side language, visit http://www.w3schools.com/asp/default.asp
Good luck, and happy coding!
P.S. Sorry if I repeated anything previously said (it took a long time to write this out!), or if I made any stupid errors I made writing this.
[right][snapback]280546[/snapback][/right]
You like quoted my Java server/client techer on what he said the first day of class
