Download the font to Desktop.
------------------------------
1. Press Alt+F2
2. Type nautilus, Press Enter, then it will be the Home Directoy.
3. Press Ctrl+H, The The Hidden Folders will show
4. Create a Folder Named .fonts (remember the name is not "fonts" but ".fonts")
5. Paste Your .ttf fonts in the .fonts directory
6. Restart the machine or Logoff then Logon.
Saturday, January 23, 2010
Thursday, January 21, 2010
WHAT IS PHP
PHP is a server-side scripting language. A server-side scripting language is one, which has the capability of executing the script on the server and serving the output as an HTML file. Server-side scripts have the main advantage of interacting with databases, as well as performing all types of server manipulations directly. Server-side scripting languages can manipulate the data which is received from web forms, anywhere on the Net.
But this is not the case with client-side scripts such as JavaScript and VBScript. However, there are exceptions where, client-side scripts can also be used for server-side scripting, but this is limited to some extent.
PHP is a cross-platform support language, which means, PHP can run on various platforms such as Linux, Windows etc. Web servers such as PWS, IIS and Apache can be configured to work with PHP.
PHP is very much compatible with MYSQL and POSTGRESQL Databases. PHP also can be programmed to interact with any database right from a simple text file to DB2. It is believed that PHP's ability to interact with databases is greater than any other scripting languages
PHP has many advantages over other scripting languages. Some of the important highlights are as follows:
Speed - PHP is considered to be the fastest of the scripting languages. You can really feel the speed when you implement scripts live on the web. Normally when you try to connect a database and fetch certain data, it takes time to connect the database, execute the statement and get the data across.
Because of its high performance in terms of speed, PHP is being used for some of the important Web server administration such as mail functionality.
Open Source - PHP is open source. This means users are given a free license to remodel or recode PHP, according to their wishes. You might wonder how this is possible without source code but source code is shipped with PHP - it is open source.
Multi Platform - PHP supports various Plat forms, which means PHP can be installed on almost all operating systems such as Windows-x and Linux, just choose the appropriate version to download and follow the instructions given in the Manual accordingly.
Easy Syntax - PHP syntax is quite easy to code. It is similar to that of the C language. If you are new to the programming environment however, getting used to the syntax may be a bit difficult.
But this is not the case with client-side scripts such as JavaScript and VBScript. However, there are exceptions where, client-side scripts can also be used for server-side scripting, but this is limited to some extent.
PHP is a cross-platform support language, which means, PHP can run on various platforms such as Linux, Windows etc. Web servers such as PWS, IIS and Apache can be configured to work with PHP.
PHP is very much compatible with MYSQL and POSTGRESQL Databases. PHP also can be programmed to interact with any database right from a simple text file to DB2. It is believed that PHP's ability to interact with databases is greater than any other scripting languages
PHP has many advantages over other scripting languages. Some of the important highlights are as follows:
Speed - PHP is considered to be the fastest of the scripting languages. You can really feel the speed when you implement scripts live on the web. Normally when you try to connect a database and fetch certain data, it takes time to connect the database, execute the statement and get the data across.
Because of its high performance in terms of speed, PHP is being used for some of the important Web server administration such as mail functionality.
Open Source - PHP is open source. This means users are given a free license to remodel or recode PHP, according to their wishes. You might wonder how this is possible without source code but source code is shipped with PHP - it is open source.
Multi Platform - PHP supports various Plat forms, which means PHP can be installed on almost all operating systems such as Windows-x and Linux, just choose the appropriate version to download and follow the instructions given in the Manual accordingly.
Easy Syntax - PHP syntax is quite easy to code. It is similar to that of the C language. If you are new to the programming environment however, getting used to the syntax may be a bit difficult.
HTTP
This HTTP tutorial provides information about HTTP requeste including HTTP request headers, HTTP response headers, Entity headers, and CGI variables. Some parts of this HTTP tutorial are quoted from RFC 2616. This is stated in the first paragraph on pages that this is done on. This is done to provide an easier reference about HTTP headers. For details the reader is encouraged to read the RFC.
HTTP Reference IntroductionHTTP characteristics:
Stateless - Each transaction between the client and server is independent and no state is set based on a previous transaction or condition. Uses requests from the client to the server and responses from the server to the client for sending and receiving data. HTTP 1.1 is defined by RFC 2616. This document only highlights some mainpoints of the HTTP 1.1 definitions and for detailed information, the readershould read RFC 2616.
From RFC 2616:
" HTTP messages consist of requests from client to server and responsesfrom server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the genericmessage format of RFC 822 [9] for transferring entities (the payload of themessage). Both types of message consist of a start-line, zero or more headerfields (also known as "headers"), an empty line (i.e., a line with nothingpreceding the CRLF) indicating the end of the header fields, and possibly amessage-body.
generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-LineHTTP header fields, which include general-header (section 4.5),request-header (section 5.3), response-header (section 6.2), and entity-header(section 7.1) fields, follow the same generic format as that given in Section3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon(":") and the field value. Field names are case-insensitive. Thefield value MAY be preceded by any amount of LWS, though a single SP ispreferred. Header fields can be extended over multiple lines by preceding eachextra line with at least one SP or HT. "
HTTP utilizes headers at the start of each message.
Common Gateway Interface (CGI)CGI is required in order for information passed from the client to theserver using HTTP to be processed by a program which is running on the server.CGI is a defined standard that provides for the passing of data between a webserver and a CGI application. The CGI defines a set of environment variablesthat are used to pass the data. A CGI application may be written in C, C++,Perl, Unix shells, TCL, JAVA, visual basic or other languages. The CGIvariables may be set on the client side using client side embedded script codesuch as JAVA script or VB script.
HTTP Request Headers
This page provides information about HTTP request headers. It provides a list of request methods and HTTP request header fields. The information on this page includes partial quotes from RFC 2616 that are somewhat re-organized.
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
Request = Request-Line ;
*(( general-header ;
| request-header ;
| entity-header ) CRLF) ;
CRLF
[ message-body ] ;
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive" Methods are:
OPTIONS - Represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. GET - Retrieve whatever information (in the form of an entity) is identified by the Request-URI. HEAD - Identical to GET except that the server MUST NOT return a message-body in the response. POST - Used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles Providing a block of data, such as the result of submitting a form, to a data-handling process Extending a database through an append operation. PUT - Requests that the enclosed entity be stored under the supplied Request-URI. DELETE - Requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. TRACE - Used to invoke a remote, application-layer loop- back of the request message. CONNECT - Reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]). The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority
The four options for Request-URI aredependent on the nature of the request. The asterisk "*" means thatthe request does not apply to a particular resource, but to the server itself,and is only allowed when the method used does not necessarily apply to aresource. One example would be
OPTIONS * HTTP/1.1
The absoluteURI form is REQUIREDwhen the request is being made to a proxy. The proxy is requested to forwardthe request or service it from a valid cache, and return the response. Notethat the proxy MAY forward the request on to another proxy or directly to theserver specified by the absoluteURI. In order to avoid request loops, a proxyMUST be able to recognize all of its server names, including any aliases, localvariations, and the numeric IP address. An example Request-Line would be:
GEThttp://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Request header fields:
ACCEPT - Can be used to specify certain media types, in MIME format, which are acceptable for the response from the web server Contains a list of media types, in MIME format, that the Web browser can accept from the Web server. Accept-Charset - Can be used to indicate what character sets are acceptable for the response. This field allows clients capable of understanding more comprehensive or special- purpose character sets to signal that capability to a server which is capable of representing documents in those character sets. ACCEPT-ENCODING - Tells the web server what document encoding methods the Web browser supports. Examples of its use are: · Accept-Encoding: compress, gzip
· Accept-Encoding:
· Accept-Encoding: *
· Accept-Encoding: compress;q=0.5,gzip;q=1.0
· Accept-Encoding: gzip;q=1.0,identity; q=0.5, *;q=0
ACCEPT-LANGUAGE - Tells the web server the web browser's preferred natural language. AUTHORIZATION - The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. Expect - Used to indicate that particular server behaviors are required by the client. FROM - An Internet e-mail address for the human user who controls the requesting user agent. The user's e-mail address who sent the HTTP request. This is not supported by most browsers. Host - Specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource. If-Match - Used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. IF-MODIFIED-SINCE - This is a HTTP data value that tells the server to only return the requested file if it was modified after the date. Form: If-Modified-Since= "If-Modified-Since" ":" HTTP-date
Example:
If-Modified-Since:Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match - Used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist. If-Range - If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body. The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'. If-Unmodified-Since - Used with a method to make it conditional. If the requested resource has not been modified since the time specified in this field, the server SHOULD perform the requested operation as if the If-Unmodified-Since header were not present. Max-Forwards - Provides a mechanism with the TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. Proxy-Authorization - Allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. Range - Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity. (However, not all clients and servers need to support byte- range operations.) REFERER - The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. This is the URI of the document that the user clicked on to get the current document. TE - Indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters . USER-AGENT - Contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. This is information about the client web browser such as Mozilla/4.01 [en] (Win95; I). HTTP Response Headers This page provides a listing of HTTP response headers and what they indicate. The information on this page includes partial quotes from RFC 2616 that are somewhat re-organized.
The response header field is:
Request = Status-Line ; *(( general-header ; | response-header ; | entity-header ) CRLF) ; CRLF [ message-body ] ; The status-line consists "of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
1xx: Informational - Request received, continuing process 100 - Continue 101 - Switching Protocols 2xx: Success - The action was successfully received, understood, and accepted 200 - OK 201 - Created 202 - Accepted 203 - Non-Authoritative Information 204 - No Content 205 - Reset Content 206 - Partial Content 3xx: Redirection - Further action must be taken in order to complete the request 300 - Multiple Choices 301 - Moved Permanently 302 - Found 303 - See Other 304 - Not Modified 305 - Use Proxy 307 - Temporary Redirect 4xx: Client Error - The request contains bad syntax or cannot be fulfilled 400 - Bad Request 401 - Unauthorized 402 - Payment Required 403 - Forbidden 404 - Not Found 405 - Method Not Allowed 406 - Not Acceptable 407 - Proxy Authentication Required 408 - Request Time-out 409 - Conflict 410 - Gone 411 - Length Required 412 - Precondition Failed 413 - Request Entity Too Large 414 - Request-URI Too Large 415 - Unsupported Media Type 416 - Requested range not satisfiable 417 - Expectation Failed 5xx: Server Error - The server failed to fulfill an apparently valid request 500 - Internal Server Error 501 - Not Implemented 502 - Bad Gateway 503 - Service Unavailable 504 - Gateway Time-out 505 - HTTP Version not supported extension-code = 3DIGIT
Reason-Phrase = *
Response Header"The response-header fields allow the server to pass additionalinformation about the response which cannot be placed in the Status- Line.These header fields give information about the server and about further accessto the resource identified by the Request-URI."
Accept-Ranges - The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource. Age - The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. ETag - The ETag response-header field provides the current value of the entity tag for the requested variant. Location - The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Proxy-Authenticate - The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. Retry-After - The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. Server - The Server response-header field contains information about the software used by the origin server to handle the request. Vary - The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. WWW-Authenticate - The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. HTTP Entity Headers
This page provides a listing of HTTP entity headers and what they are used for. Entity headers:
ALLOW - Lists the set of methods ( for the web browser) supported by the resource(web server) identified by the Request-URI.. It lists the request methods (GET, POST, etc) allowed by the server for the client. CONTENT-ENCODING - This header describes the content encoding the returned document is formatted in. An example is: Content-Encoding:gzip
CONTENT-LANGUAGE - Describes the natural language for the document ot be returned to the client web browser. CONTENT-LENGTH - The size of the document being returned in decimal number of OCTETs (bytes). CONTENT-LOCATION - The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. Content-MD5 - An MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.) CONTENT-TYPE - Iindicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. In short, it tells the web browser What MIME type the document is that is being sent to it. An example: Content-Type:text/html; charset=ISO-8859-4
CONTENT-RANGE - Sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. DATE - Represents the date and time at which the message was originated. EXPIRES - The date/time after which the response is considered stale. LAST-MODIFIED - Indicates the date and time at which the origin server believes the variant (document being sent to the browser) was last modified. CGI Variables
CGI Environment variables are the main source of information which your server side scripts can use.
AUTH_TYPE - Describes the authentication method used by the web browser if any authentication method was used. This is not set unless the script is protected. CONTENT_LENGTH - This is used for scripts that are receiving form data using the POST method. This variable tells the byte length of the CGI input data stream. This is required to read the data from the standard input with the POST method. CONTENT_TYPE - Tells the media type of data being received from the user. this is used for scripts called using the POST method. DOCUMENT_ROOT - The root path to the home HTML page for the server. Example: /home/httpd/html
GATEWAY_INTERFACE - The version of the common gateway interface (CGI) specification being used to exchange the data between the client and server. this is normally CGI/1.1 for the current revision level of 1.1. Example: CGI/1.1
PATH_INFO - Extra path information added to the end of the URL that accessed the server side script program. PATH_TRANSLATED - A translated version of the PATH_INFO variable translated by the webserver from virtual to physical path information. QUERY_STRING - This string contains any information at the end of the server side script path that followed a question mark. Used to return data if the GET method was used by a form. There are length restrictions to the QUERY_STRING. Example of how to set it in HTML:
Theinformation after the ? is the QUERY_STRING which is "mainpage" inthis case. How it looks on the server side
mainpage
REMOTE_ADDR - The IP address of the client computer. Example: 132.15.28.124
REMOTE_HOST - The fully qualified domain name of the client machine making the HTTP request. It may not be possible to determine this name since many client computers names are not recorded in the DNS system. Example: comp11.mycompanyproxy.com
REMOTE_IDENT - The ability to use this variable is limited to servers that support RFC 931. This variable may contain the client machine's username, but it is intended to be used for logging purposes only, when it is available. REMOTE_PORT - The clients requesting port. An example: 3465
REMOTE_USER - If the CGI script was protected and the user had to be logged in to get access to the script, this value will contain the user's log in name REQUEST_URI - The path to the requested file by the client. An example: /cgi-bin/join.pl?button=on
REQUEST_METHOD - This describes the request method used by the browser which is normally GET, POST, or HEAD. SCRIPT_NAME - The virtual path of the CGI script being executed. Example: /cgi-bin/join.pl
SCRIPT_FILENAME - Example: /home/httpd/cgi-bin/join.pl
SERVER_ADMIN - The e-mail address of the server administrator. Example: webadmin@myhost.mycompany.org
SERVER_NAME - The server hostname, IP address or DNS alias name shown as a self referencing URL. This does not include the protocol identifier such as "HTTP:", the machine name, or port number. Example: myhost
SERVER_PORT - The port number the HTTP requests and responses are being sent on. Example: 80
SERVER_PROTOCOL - This value is normally HTTP which describes the protocol being used between the client and server computers. Example: HTTP/1.1
SERVER_SIGNATURE - Server information specifying the name and version of the web server and the port being serviced. Example: Apache/1.3.12Server at mdct-dev3 Port 80
SERVER_SOFTWARE - The name and version of the web server. Example: Apache/1.3.12(Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.21
HTTP_ACCEPT - The media types of data that the client browser can accept. these data types are separated by commas. An example: image/gif,image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel,application/msword, application/vnd.ms-powerpoint, */*
HTTP_ACCEPT_ENCODING An example: gzip,deflate
HTTP_ACCEPT_LANGUAGE - The language the client browser accepts. Example: en-us
HTTP_COOKIE - Used as an environment variable that contains cookies associated with the server domain from the browser. HTTP_FORWARDED An example: byhttp://proxy-nt1.yourcompany.org:8080 (Netscape-Proxy/3.5)
HTTP_HOST An example: yourwebhost.yourcompany.org
HTTP_PRAGMA - An example: No-Cache
HTTP_REFERER - The page address where the HTTP request originated. An example: http://ctdp.tripod.com/independent/web/cgi/cgimanual/index.html
HTTP_USER_AGENT - The name of the client web browser being used to make the request. Example: Mozilla/4.0(compatible; MSIE 4.01; Windows 95)
CGI Operation CGI program response and Name/Value pairs Provides more detail about CGI program response and name value pairs during CGI operation. Data sent from forms, as you can see from the example on the previous page, has the following characteristics:
Information is sent in the form of a name and value pair. Each name/value pair begins with an & sign. The name/value pair are seperated by the equals (=) sign between the name and the value. They are URL encoded. URL encoding changes some characters to placeholders and substitutes a hexadecimal ASCII value for some characters. To process the data in the server follow this sequence:
Get the data from the proper variable depending on whether the POST or GET method was used. Change any placeholders to their correct values (Change any + signs to spaces). Split each group of name value pairs into an array of strings. Convert hexadecimal values back to ASCII character equivalents. Evaluate the respective names and values. See the "Poll Receiving" section of the Perl manual in this CGI section for an example of this process.
Responding to the Client Any output to be returned to the client web browser can be sent to the standard output of the CGI program as in the following line:
print "Content-type: text/html", "\n\n
This will appear on the clients' web browser.
"; # MIME header.
Two blank lines must be placed after the parsed header.
The CGI application must send a parsed header to it's standard output which is intercepted by the web server. From the parsed header, the web server will create the required non-parsed HTTP response header to be sent to the client. The parsed header must contain a server directive which may include one or more of:
Content-type - Indicates the MIME type of the data being sent back to the client. Location - The URL the client web browser should be directed to. Status - A HTTP status code. Common codes are 200 (OK) and 404 (not found). The CGI application may also send a HTTP response header. The server createsa non-parsed header from the CGI parsed information and sends it to the client.The following is a valid non-parsed header: "
HTTP/1.0 200 OKServer: Netscape-Communications/3.0Content-type: text/htmlUsing the client to call a CGI applicationMethods for a client to call a CGI application:
An action attribute in an HTML FORM tag specifies the CGI application to run when the user presses the FORM submit button. As described in the introduction, the POST or GET methods may be used to send the data. The data is sent as part of the standard input or as the QUERY_STRING if POST or GET are used respectively. Server-side includes. The Form of a SSI statement as found on an HTML page:
The output from the server side include script isplcaed into the HTML page at the location where the SSI call was made. See theSSI manual for maor information on server side includes.
An HTML IMG tag may be used to indirectly call the CGI application with a line like the following:
It is expected that the CGI program will generatean image to be sent back to the client web browser. See the "Printing aFile" section in the Perl manual for an example about how to do this.
Client side script programs embedded into the HTML page such as JavaScript may be used to call a CGI application program.
Using HTTP
To understand how HTTP is used there are example applications such as a web hit counter and forms processing in the Perl manual in the CGI section of this site. These applications run on the server side.
HTTP Terms
This page provides some common HTTP terms with definitions.
Connection - A virtual circuit created at the netowrk model transport layer. HTTP - Hypertext Transfer Protocol. Message - A sequence of octets used as a basic unit of HTTP communication. MIME - Multipurpose Internet Mail Extensions are used to specify file types as used by the HTTP protocol. Request - A request by a client computer usually for a page or file. Response - The server response to a HTTP request that provides the requested item. Transaction - The request and response combination which makes up a single interaction between the client browser and the web server. URI - Uniform Resource Identifier.
HTTP Reference IntroductionHTTP characteristics:
Stateless - Each transaction between the client and server is independent and no state is set based on a previous transaction or condition. Uses requests from the client to the server and responses from the server to the client for sending and receiving data. HTTP 1.1 is defined by RFC 2616. This document only highlights some mainpoints of the HTTP 1.1 definitions and for detailed information, the readershould read RFC 2616.
From RFC 2616:
" HTTP messages consist of requests from client to server and responsesfrom server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the genericmessage format of RFC 822 [9] for transferring entities (the payload of themessage). Both types of message consist of a start-line, zero or more headerfields (also known as "headers"), an empty line (i.e., a line with nothingpreceding the CRLF) indicating the end of the header fields, and possibly amessage-body.
generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-LineHTTP header fields, which include general-header (section 4.5),request-header (section 5.3), response-header (section 6.2), and entity-header(section 7.1) fields, follow the same generic format as that given in Section3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon(":") and the field value. Field names are case-insensitive. Thefield value MAY be preceded by any amount of LWS, though a single SP ispreferred. Header fields can be extended over multiple lines by preceding eachextra line with at least one SP or HT. "
HTTP utilizes headers at the start of each message.
Common Gateway Interface (CGI)CGI is required in order for information passed from the client to theserver using HTTP to be processed by a program which is running on the server.CGI is a defined standard that provides for the passing of data between a webserver and a CGI application. The CGI defines a set of environment variablesthat are used to pass the data. A CGI application may be written in C, C++,Perl, Unix shells, TCL, JAVA, visual basic or other languages. The CGIvariables may be set on the client side using client side embedded script codesuch as JAVA script or VB script.
HTTP Request Headers
This page provides information about HTTP request headers. It provides a list of request methods and HTTP request header fields. The information on this page includes partial quotes from RFC 2616 that are somewhat re-organized.
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
Request = Request-Line ;
*(( general-header ;
| request-header ;
| entity-header ) CRLF) ;
CRLF
[ message-body ] ;
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive" Methods are:
OPTIONS - Represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. GET - Retrieve whatever information (in the form of an entity) is identified by the Request-URI. HEAD - Identical to GET except that the server MUST NOT return a message-body in the response. POST - Used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles Providing a block of data, such as the result of submitting a form, to a data-handling process Extending a database through an append operation. PUT - Requests that the enclosed entity be stored under the supplied Request-URI. DELETE - Requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. TRACE - Used to invoke a remote, application-layer loop- back of the request message. CONNECT - Reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]). The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority
The four options for Request-URI aredependent on the nature of the request. The asterisk "*" means thatthe request does not apply to a particular resource, but to the server itself,and is only allowed when the method used does not necessarily apply to aresource. One example would be
OPTIONS * HTTP/1.1
The absoluteURI form is REQUIREDwhen the request is being made to a proxy. The proxy is requested to forwardthe request or service it from a valid cache, and return the response. Notethat the proxy MAY forward the request on to another proxy or directly to theserver specified by the absoluteURI. In order to avoid request loops, a proxyMUST be able to recognize all of its server names, including any aliases, localvariations, and the numeric IP address. An example Request-Line would be:
GEThttp://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Request header fields:
ACCEPT - Can be used to specify certain media types, in MIME format, which are acceptable for the response from the web server Contains a list of media types, in MIME format, that the Web browser can accept from the Web server. Accept-Charset - Can be used to indicate what character sets are acceptable for the response. This field allows clients capable of understanding more comprehensive or special- purpose character sets to signal that capability to a server which is capable of representing documents in those character sets. ACCEPT-ENCODING - Tells the web server what document encoding methods the Web browser supports. Examples of its use are: · Accept-Encoding: compress, gzip
· Accept-Encoding:
· Accept-Encoding: *
· Accept-Encoding: compress;q=0.5,gzip;q=1.0
· Accept-Encoding: gzip;q=1.0,identity; q=0.5, *;q=0
ACCEPT-LANGUAGE - Tells the web server the web browser's preferred natural language. AUTHORIZATION - The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. Expect - Used to indicate that particular server behaviors are required by the client. FROM - An Internet e-mail address for the human user who controls the requesting user agent. The user's e-mail address who sent the HTTP request. This is not supported by most browsers. Host - Specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource. If-Match - Used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. IF-MODIFIED-SINCE - This is a HTTP data value that tells the server to only return the requested file if it was modified after the date. Form: If-Modified-Since= "If-Modified-Since" ":" HTTP-date
Example:
If-Modified-Since:Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match - Used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist. If-Range - If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body. The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'. If-Unmodified-Since - Used with a method to make it conditional. If the requested resource has not been modified since the time specified in this field, the server SHOULD perform the requested operation as if the If-Unmodified-Since header were not present. Max-Forwards - Provides a mechanism with the TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. Proxy-Authorization - Allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. Range - Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity. (However, not all clients and servers need to support byte- range operations.) REFERER - The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. This is the URI of the document that the user clicked on to get the current document. TE - Indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters . USER-AGENT - Contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. This is information about the client web browser such as Mozilla/4.01 [en] (Win95; I). HTTP Response Headers This page provides a listing of HTTP response headers and what they indicate. The information on this page includes partial quotes from RFC 2616 that are somewhat re-organized.
The response header field is:
Request = Status-Line ; *(( general-header ; | response-header ; | entity-header ) CRLF) ; CRLF [ message-body ] ; The status-line consists "of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
1xx: Informational - Request received, continuing process 100 - Continue 101 - Switching Protocols 2xx: Success - The action was successfully received, understood, and accepted 200 - OK 201 - Created 202 - Accepted 203 - Non-Authoritative Information 204 - No Content 205 - Reset Content 206 - Partial Content 3xx: Redirection - Further action must be taken in order to complete the request 300 - Multiple Choices 301 - Moved Permanently 302 - Found 303 - See Other 304 - Not Modified 305 - Use Proxy 307 - Temporary Redirect 4xx: Client Error - The request contains bad syntax or cannot be fulfilled 400 - Bad Request 401 - Unauthorized 402 - Payment Required 403 - Forbidden 404 - Not Found 405 - Method Not Allowed 406 - Not Acceptable 407 - Proxy Authentication Required 408 - Request Time-out 409 - Conflict 410 - Gone 411 - Length Required 412 - Precondition Failed 413 - Request Entity Too Large 414 - Request-URI Too Large 415 - Unsupported Media Type 416 - Requested range not satisfiable 417 - Expectation Failed 5xx: Server Error - The server failed to fulfill an apparently valid request 500 - Internal Server Error 501 - Not Implemented 502 - Bad Gateway 503 - Service Unavailable 504 - Gateway Time-out 505 - HTTP Version not supported extension-code = 3DIGIT
Reason-Phrase = *
Response Header"The response-header fields allow the server to pass additionalinformation about the response which cannot be placed in the Status- Line.These header fields give information about the server and about further accessto the resource identified by the Request-URI."
Accept-Ranges - The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource. Age - The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. ETag - The ETag response-header field provides the current value of the entity tag for the requested variant. Location - The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Proxy-Authenticate - The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. Retry-After - The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. Server - The Server response-header field contains information about the software used by the origin server to handle the request. Vary - The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. WWW-Authenticate - The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. HTTP Entity Headers
This page provides a listing of HTTP entity headers and what they are used for. Entity headers:
ALLOW - Lists the set of methods ( for the web browser) supported by the resource(web server) identified by the Request-URI.. It lists the request methods (GET, POST, etc) allowed by the server for the client. CONTENT-ENCODING - This header describes the content encoding the returned document is formatted in. An example is: Content-Encoding:gzip
CONTENT-LANGUAGE - Describes the natural language for the document ot be returned to the client web browser. CONTENT-LENGTH - The size of the document being returned in decimal number of OCTETs (bytes). CONTENT-LOCATION - The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. Content-MD5 - An MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.) CONTENT-TYPE - Iindicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. In short, it tells the web browser What MIME type the document is that is being sent to it. An example: Content-Type:text/html; charset=ISO-8859-4
CONTENT-RANGE - Sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. DATE - Represents the date and time at which the message was originated. EXPIRES - The date/time after which the response is considered stale. LAST-MODIFIED - Indicates the date and time at which the origin server believes the variant (document being sent to the browser) was last modified. CGI Variables
CGI Environment variables are the main source of information which your server side scripts can use.
AUTH_TYPE - Describes the authentication method used by the web browser if any authentication method was used. This is not set unless the script is protected. CONTENT_LENGTH - This is used for scripts that are receiving form data using the POST method. This variable tells the byte length of the CGI input data stream. This is required to read the data from the standard input with the POST method. CONTENT_TYPE - Tells the media type of data being received from the user. this is used for scripts called using the POST method. DOCUMENT_ROOT - The root path to the home HTML page for the server. Example: /home/httpd/html
GATEWAY_INTERFACE - The version of the common gateway interface (CGI) specification being used to exchange the data between the client and server. this is normally CGI/1.1 for the current revision level of 1.1. Example: CGI/1.1
PATH_INFO - Extra path information added to the end of the URL that accessed the server side script program. PATH_TRANSLATED - A translated version of the PATH_INFO variable translated by the webserver from virtual to physical path information. QUERY_STRING - This string contains any information at the end of the server side script path that followed a question mark. Used to return data if the GET method was used by a form. There are length restrictions to the QUERY_STRING. Example of how to set it in HTML:
Theinformation after the ? is the QUERY_STRING which is "mainpage" inthis case. How it looks on the server side
mainpage
REMOTE_ADDR - The IP address of the client computer. Example: 132.15.28.124
REMOTE_HOST - The fully qualified domain name of the client machine making the HTTP request. It may not be possible to determine this name since many client computers names are not recorded in the DNS system. Example: comp11.mycompanyproxy.com
REMOTE_IDENT - The ability to use this variable is limited to servers that support RFC 931. This variable may contain the client machine's username, but it is intended to be used for logging purposes only, when it is available. REMOTE_PORT - The clients requesting port. An example: 3465
REMOTE_USER - If the CGI script was protected and the user had to be logged in to get access to the script, this value will contain the user's log in name REQUEST_URI - The path to the requested file by the client. An example: /cgi-bin/join.pl?button=on
REQUEST_METHOD - This describes the request method used by the browser which is normally GET, POST, or HEAD. SCRIPT_NAME - The virtual path of the CGI script being executed. Example: /cgi-bin/join.pl
SCRIPT_FILENAME - Example: /home/httpd/cgi-bin/join.pl
SERVER_ADMIN - The e-mail address of the server administrator. Example: webadmin@myhost.mycompany.org
SERVER_NAME - The server hostname, IP address or DNS alias name shown as a self referencing URL. This does not include the protocol identifier such as "HTTP:", the machine name, or port number. Example: myhost
SERVER_PORT - The port number the HTTP requests and responses are being sent on. Example: 80
SERVER_PROTOCOL - This value is normally HTTP which describes the protocol being used between the client and server computers. Example: HTTP/1.1
SERVER_SIGNATURE - Server information specifying the name and version of the web server and the port being serviced. Example: Apache/1.3.12Server at mdct-dev3 Port 80
SERVER_SOFTWARE - The name and version of the web server. Example: Apache/1.3.12(Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.21
HTTP_ACCEPT - The media types of data that the client browser can accept. these data types are separated by commas. An example: image/gif,image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel,application/msword, application/vnd.ms-powerpoint, */*
HTTP_ACCEPT_ENCODING An example: gzip,deflate
HTTP_ACCEPT_LANGUAGE - The language the client browser accepts. Example: en-us
HTTP_COOKIE - Used as an environment variable that contains cookies associated with the server domain from the browser. HTTP_FORWARDED An example: byhttp://proxy-nt1.yourcompany.org:8080 (Netscape-Proxy/3.5)
HTTP_HOST An example: yourwebhost.yourcompany.org
HTTP_PRAGMA - An example: No-Cache
HTTP_REFERER - The page address where the HTTP request originated. An example: http://ctdp.tripod.com/independent/web/cgi/cgimanual/index.html
HTTP_USER_AGENT - The name of the client web browser being used to make the request. Example: Mozilla/4.0(compatible; MSIE 4.01; Windows 95)
CGI Operation CGI program response and Name/Value pairs Provides more detail about CGI program response and name value pairs during CGI operation. Data sent from forms, as you can see from the example on the previous page, has the following characteristics:
Information is sent in the form of a name and value pair. Each name/value pair begins with an & sign. The name/value pair are seperated by the equals (=) sign between the name and the value. They are URL encoded. URL encoding changes some characters to placeholders and substitutes a hexadecimal ASCII value for some characters. To process the data in the server follow this sequence:
Get the data from the proper variable depending on whether the POST or GET method was used. Change any placeholders to their correct values (Change any + signs to spaces). Split each group of name value pairs into an array of strings. Convert hexadecimal values back to ASCII character equivalents. Evaluate the respective names and values. See the "Poll Receiving" section of the Perl manual in this CGI section for an example of this process.
Responding to the Client Any output to be returned to the client web browser can be sent to the standard output of the CGI program as in the following line:
print "Content-type: text/html", "\n\n
This will appear on the clients' web browser.
"; # MIME header.
Two blank lines must be placed after the parsed header.
The CGI application must send a parsed header to it's standard output which is intercepted by the web server. From the parsed header, the web server will create the required non-parsed HTTP response header to be sent to the client. The parsed header must contain a server directive which may include one or more of:
Content-type - Indicates the MIME type of the data being sent back to the client. Location - The URL the client web browser should be directed to. Status - A HTTP status code. Common codes are 200 (OK) and 404 (not found). The CGI application may also send a HTTP response header. The server createsa non-parsed header from the CGI parsed information and sends it to the client.The following is a valid non-parsed header: "
HTTP/1.0 200 OKServer: Netscape-Communications/3.0Content-type: text/htmlUsing the client to call a CGI applicationMethods for a client to call a CGI application:
An action attribute in an HTML FORM tag specifies the CGI application to run when the user presses the FORM submit button. As described in the introduction, the POST or GET methods may be used to send the data. The data is sent as part of the standard input or as the QUERY_STRING if POST or GET are used respectively. Server-side includes. The Form of a SSI statement as found on an HTML page:
The output from the server side include script isplcaed into the HTML page at the location where the SSI call was made. See theSSI manual for maor information on server side includes.
An HTML IMG tag may be used to indirectly call the CGI application with a line like the following:
It is expected that the CGI program will generatean image to be sent back to the client web browser. See the "Printing aFile" section in the Perl manual for an example about how to do this.
Client side script programs embedded into the HTML page such as JavaScript may be used to call a CGI application program.
Using HTTP
To understand how HTTP is used there are example applications such as a web hit counter and forms processing in the Perl manual in the CGI section of this site. These applications run on the server side.
HTTP Terms
This page provides some common HTTP terms with definitions.
Connection - A virtual circuit created at the netowrk model transport layer. HTTP - Hypertext Transfer Protocol. Message - A sequence of octets used as a basic unit of HTTP communication. MIME - Multipurpose Internet Mail Extensions are used to specify file types as used by the HTTP protocol. Request - A request by a client computer usually for a page or file. Response - The server response to a HTTP request that provides the requested item. Transaction - The request and response combination which makes up a single interaction between the client browser and the web server. URI - Uniform Resource Identifier.
Subscribe to:
Posts (Atom)
