URL and request parameters. Post - What method is used to transmit an http request in a form and without a form? How to make http requests

HTTP (Hyper Text Transport Protocol) is the very language in which browsers “talk” to web servers, the most important Internet protocol...

Types of requests

Requests can be divided into two types:

1. GET;
2. POST.

GET used when typing a site address in the browser line or follow the link. POST serves to submit forms, for example, when registering on a website or publishing a comment on an article. To submit a form, you usually need to click the “Submit” button or something similar:

For simplicity understanding the difference can be represented as follows:

1. GET used for reading websites (we read the Internet);
2. POST serves for publication information on websites (we write Internet)

URL and request parameters

In both cases it is required URL(Uniform Resource Locator) of the requested document.

URL - this is the address pages on the Internet. As a rule, it looks like this:
http://<хост>/<путь>
For example:
http://www.example.ru/about.php
Or this, if you need to pass parameters to the script:
http://<хост>/<путь>?<параметры>
Where<параметры>is a set of pairs of the form:
<имя>=<значение>
separated by symbol & .
Example:
http://www.example.ru/news.php?id=100&show_comments=yes

You may experience question: For what transfer to script parameters? Dynamic page(aka script), unlike static, can produce various information. For example, a news feed script displays either a list of latest news announcements or the entire text of a specific article. The script understands what exactly the user wants to see based on the parameters passed to it.

It could work like this. Getting a list of the latest news: http://www.example.ru/news.php(URL without parameters). Receipt full text news article: http://www.example.ru/news.php ?id=1 (The URL includes the news number as a parameter).

Handling URL Parameters

And now we will write a script for this very news feed. She will have two modes:

We will have three news in total:

1. “They will answer for quality. They have started to control food products in a new way”;
2. “Warsaw does not disclose the list of possible measures against Minsk”;
3. "Pavel Astakhov intends to seek the resignation of a number of officials in Udmurtia"

ATTENTION! The example is simplified. Nobody ever stores news in script code. Such information should be stored in a database. But this is the subject of a completely different lesson!

Now it’s important for us to learn how to process parameters passed via URL. So, create a news.php file:

"; echo " "; echo " "; echo ""; echo " "; echo "

"; for ($i = 0; $i< count($news); $i++) { echo "
• "; echo ""; echo $news[$i]; echo ""; echo "
"; echo "

"; echo ""; echo ""; ) // Function for displaying a specific news. function show_item($news, $id) ( echo " "; echo " "; echo " "; echo ""; echo " "; echo "Back to news list"; echo "

"; echo $news[$id - 1]; echo "

"; echo "

"; echo "Imagine there is a lot of text and pictures :)"; echo "

"; echo ""; echo ""; ) ) // Entry point. // Create an array of news. $news = array(); $news = "They will answer for the quality. They began to control food products in a new way."; $news = "Warsaw does not disclose the list of possible measures against Minsk"; $news = "Pavel Astakhov intends to seek the resignation of a number of Udmurtia officials"; // Was the news id passed as a parameter? if (isset($_GET["id"])) ( show_item($news, $_GET["id"]); ) else ( show_list($news); ) ?>

Now let's look at it in detail, what did we write?

First we announce two functions who will generate HTML. The first displays a list of news, the second - the text of a specific news. Control will be transferred to these functions only when we call them. We'll come back to them later.

Execution script begins from the place where the comment is marked entry point. We create an array consisting of three news items. Let us remind you that numbering of elements in an array starts from zero!

Next checking, was there passed id news as a parameter. Parameters passed via URL are stored in the $_GET system variable. It is an associative array (or, in other words, a dictionary).

Recall that an associative array (or dictionary) is a data structure that contains key-value pairs.

Dictionary keys $_GET are the names of the parameters. Function isset() returns true if variable defined. Thus,
if (isset($_GET["id"]))
should read: "if the request URL contains the id parameter".

Now let's get back to functions. Everything is simple here, but we would like to draw attention to two points.

Firstly , it may not be entirely clear why we add to $i one, and in the other we subtract. This is done so that the user saw the URL the first news is: "news.php?id=1", not "news.php?id=0". This is good form and nothing more.

Secondly , pay attention to the line:
echo "News #$id";
Double quotes differ from single because if there are names inside them variables(with sign $ ), then they are replaced values these same variables. Line in single in quotation marks remains as is without substitution variable values.

In the next lesson we will look at how send content HTML Form filled out by the user, and process his.

We have decided that the browser (client) sends HTTP requests to the server, and the server sends HTTP responses to the client. These requests and responses are formatted according to certain rules. There is something like a syntax, how and in what sequence it should be written. There must be a strictly defined structure.

Let's take a closer look at this structure by which requests and responses are built in the HTTP protocol.

An HTTP request consists of three main parts, which appear in the order listed below. Between the headers and the body of the message there is an empty line (as a separator), it represents a line feed character.

1. Request Line

2. Message Headers

Empty string (delimiter)

3. message body (Entity Body) – optional parameter

Query string– specifies the transfer method, the URL to be accessed, and the HTTP protocol version.

Headings– describe the body of messages, transmit various parameters and other information and information.

message body- this is the data itself that is transmitted in the request. The message body is an optional parameter and may be missing.

When we receive a response request from the server, the body of the message is most often the content of the web page. But, when making requests to the server, it can also sometimes be present, for example, when we transfer the data that we filled out in the feedback form to the server.

We will look at each element of the request in more detail in the following notes.

Let's, for example, consider one real request to the server. I've highlighted each part of the request with a different color: the request line is green, the headers are orange, and the message body is blue.

Browser request:

GET / HTTP/1.1

Host: website

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

Cookie: wp-settings

Connection: keep-alive

In the following example, the message body is already present.

Server response:

HTTP/1.1 200 OK

Content-Type: text/html; charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

Keep-Alive: timeout=5

Server: Apache

X-Pingback: //site/xmlrpc.php

These are the messages exchanged between the client and server via HTTP.

By the way, I set up reports, goals and events in the Yandex Metrica and Google Analytics systems.

An HTTP request, or message, consists of three parts: the query line, and the body of the HTTP message.

Query string, or start line: in a request to the server, a line that contains the type of request (method), URI of the requested page, and version (for example HTTP/1.1). In the response from the server, this line contains the HTTP protocol version and the response code. The response code is a three-digit integer. It is usually followed by a space-separated explanatory phrase that explains the code, for example: 200 OK, or 404 Not Found.

HTTP request methods (types): GET, POST, PUT, PATCH, HEAD, DELETE, TRACE. Most often, the GET or POST methods are used in an HTTP request: GET is used to request the content of a web page at the specified URI. URI is the address of the page without specifying , for example: /internet/chto-takoe-http-zapros-soobshhenie/ instead of site/internet/chto-takoe-http-zapros-soobshhenie/. The browser can pass parameters in a GET in the URI after the "? ": GET /index.php?param1=value1¶m2=value2. In addition to the regular GET method, there are also conditional GET and partial GET. Conditional GET requests contain If-Modified-Since, If-Match, If-Range, and similar headers.

POST - used to send information to . When sending data using the POST method, it is indicated in the body of the HTTP message, and not in the address input line in the browser, as is done when sending data using the GET method. For example, when sending a comment through the form located under the article, information is transmitted to the server using the POST method. Files are also uploaded to the server using the POST method.

- this is part of the request, which contains various parameters that are used to correctly build the web page.

HTTP message body— contains data received from the server, for example a generated web page in the form of HTML code, or a resource, for example a picture.

Example HTTP messages:

HTTP request to the server:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ( KHTML, like Gecko) Chrome/40.0.2150.0 Accept-Encoding: gzip, deflate, sdch Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: wp- settings-1=hidetb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+Cookie;

Response from the server:

HTTP/1.1 200 OK - response start line: Server: nginx/1.6.2 Date: Sun, 19 Apr 2015 00:22:50 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 9431 Connection: keep-alive Keep-Alive: timeout=30 X-Powered-By: PHP/5.5.22 Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip The response body (html page) follows.

HTTP is a protocol for transferring hypertext between distributed systems. In fact, http is a fundamental element of the modern Web. As self-respecting web developers, we should know as much as possible about it.

Let's look at this protocol through the lens of our profession. In the first part, we'll go over the basics and look at requests/responses. In the next article we will look at more detailed features, such as caching, connection processing and authentication.

Also in this article I will mainly refer to the RFC 2616 standard: Hypertext Transfer Protocol -- HTTP/1.1.

HTTP Basics

HTTP enables communication between multiple hosts and clients, and supports a range of network settings.

Basically, TCP/IP is used for communication, but this is not the only possible option. By default, TCP/IP uses port 80, but others can be used.

Communication between the host and the client occurs in two stages: request and response. The client generates an HTTP request, in response to which the server provides a response (message). A little later, we will look at this scheme of work in more detail.

The current version of the HTTP protocol is 1.1, in which some new features have been introduced. In my opinion, the most important of them are: support for a constantly open connection, a new data transfer mechanism chunked transfer encoding, new headers for caching. We will look at some of this in the second part of this article.

URL

The core of web communication is the request, which is sent through the Uniform Resource Locator (URL). I'm sure you already know what a URL is, but for the sake of completeness, I decided to say a few words. The URL structure is very simple and consists of the following components:

The protocol can be either http for regular connections or https for more secure data exchange. The default port is 80. This is followed by the path to the resource on the server and a chain of parameters.

Methods

Using a URL, we define the exact name of the host we want to communicate with, but what action we need to perform can only be communicated using the HTTP method. Of course, there are several types of actions that we can take. HTTP implements the most necessary ones, suitable for the needs of most applications.

Existing methods:

GET: Access an existing resource. The URL lists all the necessary information so that the server can find and return the requested resource as a response.

POST: Used to create a new resource. A POST request usually contains all the necessary information to create a new resource.

PUT: Update the current resource. The PUT request contains the data to be updated.

DELETE: Used to delete an existing resource.

These methods are the most popular and are most often used by various tools and frameworks. In some cases, PUT and DELETE requests are sent by sending a POST, the content of which indicates the action that needs to be performed on the resource: create, update or delete.

HTTP also supports other methods:

HEAD: Similar to GET. The difference is that with this type of request no message is transmitted. The server only receives the headers. Used, for example, to determine whether a resource has been modified.

TRACE: during transmission, the request passes through many access points and proxy servers, each of which enters its own information: IP, DNS. Using this method, you can see all the intermediate information.

OPTIONS: Used to define server capabilities, settings, and configuration for a specific resource.

Status codes

In response to a request from the client, the server sends a response, which also contains a status code. This code has a special meaning so that the client can more clearly understand how to interpret the response:

1xx: Information messages

A set of these codes was introduced in HTTP/1.1. The server can send a request of the form: Expect: 100-continue, which means that the client is still sending the rest of the request. Clients running HTTP/1.0 ignore these headers.

2xx: Success messages

If the client received a code from the 2xx series, then the request was sent successfully. The most common option is 200 OK. With a GET request, the server sends a response in the body of the message. There are also other possible answers:

• 202 Accepted: The request is accepted, but may not contain the resource in the response. This is useful for asynchronous requests on the server side. The server determines whether to send the resource or not.
• 204 No Content: There is no message in the response body.
• 205 Reset Content: Instructs the server to reset the presentation of the document.
• 206 Partial Content: The response contains only part of the content. Additional headers determine the total length of the content and other information.

3xx: Redirect

A kind of message to the client about the need to take one more action. The most common use case is to redirect the client to another address.

• 301 Moved Permanently: The resource can now be found at a different URL.
• 303 See Other: The resource can temporarily be found at a different URL. The Location header contains a temporary URL.
• 304 Not Modified: The server determines that the resource has not been modified and the client needs to use the cached version of the response. To check the identity of information, ETag (Entity Tag hash) is used;

4xx: Client errors

This message class is used by the server if it decides that the request was sent in error. The most common code is 404 Not Found. This means that the resource was not found on the server. Other possible codes:

• 400 Bad Request: The question was formed incorrectly.
• 401 Unauthorized: Authentication is required to make a request. Information is transmitted through the Authorization header.
• 403 Forbidden: The server did not allow access to the resource.
• 405 Method Not Allowed: An invalid HTTP method was used to access the resource.
• 409 Conflict: the server cannot fully process the request because tries to change a newer version of a resource. This often happens with PUT requests.

5xx: Server errors

A series of codes that are used to detect a server error when processing a request. The most common: 500 Internal Server Error. Other options:

• 501 Not Implemented: The server does not support the requested functionality.
• 503 Service Unavailable: This can happen if the server has an error or is overloaded. Usually in this case, the server does not respond, and the time given for the response expires.

Request/Response Message Formats

In the following image you can see a schematic process of sending a request by the client, processing and sending a response by the server.

Let's look at the structure of a message transmitted via HTTP:

Message = *() CRLF [ ] = Request-Line | Status-Line = Field-Name ":" Field-Value

There must be a blank line between the header and body of the message. There can be several headings:

The response body can contain all or part of the information if the corresponding feature is enabled (Transfer-Encoding: chunked). HTTP/1.1 also supports the Transfer-Encoding header.

General Headings

Here are several types of headers that are used in both requests and responses:

General-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning

We have already covered some things in this article, some we will discuss in more detail in the second part.

The via header is used in a TRACE request, and is updated by all proxy servers.

The Pragma header is used to list custom headers. For example, Pragma: no-cache is the same as Cache-Control: no-cache. We'll talk more about this in part two.

The Date header is used to store the date and time of the request/response.

The Upgrade header is used to change the protocol.

Transfer-Encoding is intended to split the response into multiple chunks using Transfer-Encoding: chunked. This is a new feature in HTTP/1.1.

Entity Headers

Entity headers convey meta information about the content:

Entity-header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified

All headers prefixed with Content- provide information about the structure, encoding, and size of the message body.

The Expires header contains the expiration time and date of the entity. The value “never expires” means time + 1 code from the current moment. Last-Modified contains the time and date the entity was last modified.

Using these headers, you can specify the information necessary for your tasks.

Request Format

The request looks something like this:

Request-Line = Method SP URI SP HTTP-Version CRLF Method = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "DELETE" | "TRACE"

SP is the separator between tokens. The HTTP version is specified in HTTP-Version. The actual request looks like this:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml; q=0.9,*/*;q=0.8

List of possible request headers:

Request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referrer | TE | User-Agent

The Accept header specifies the supported mime types, language, and character encoding. The From, Host, Referer, and User-Agent headers contain information about the client. If- prefixes are intended to create conditions. If the condition does not pass, a 304 Not Modified error will occur.

Response Format

The response format differs only in the status and a number of headers. The status looks like this:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP version
• Status code
• Human-readable status message

The normal status looks something like this:

HTTP/1.1 200 OK

The response headers can be as follows:

Response-header = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate

• Age is the time in seconds when the message was created on the server.
• ETag MD5 entities to check for changes and modifications to the response.
• Location is used for redirection and contains the new URL.
• Server specifies the server where the response was generated.

I think that's enough theory for today. Now let's take a look at the tools we can use to monitor HTTP messages.

Tools for detecting HTTP traffic

There are many tools for monitoring HTTP traffic. Here are a few of them:

The most commonly used is Chrome Developers Tools:

If we talk about a debugger, you can use Fiddler:

To monitor HTTP traffic you will need curl, tcpdump and tshark.

Libraries for working with HTTP - jQuery AJAX

Since jQuery is so popular, it also has tools for handling HTTP responses for AJAX requests. Information about jQuery.ajax(settings) can be found on the official website.

By passing a settings object and using the beforeSend callback function, we can set the request headers using the setRequestHeader() method.

$.ajax(( url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); ) ));

If you want to process the request status, you can do it like this:

$.ajax(( statusCode: ( 404: function() ( alert("page not found"); ) ) ));

Bottom line

Here it is, a tour of the basics of the HTTP protocol. The second part will contain even more interesting facts and examples.

We present to you a description of the main aspects of the HTTP protocol - a network protocol that, from the early 90s to this day, allows your browser to load web pages. This article was written for those who are just starting to work with computer networks and develop network applications, and who still find it difficult to read the official specifications on their own.

HTTP- a widely used data transfer protocol, originally intended for the transfer of hypertext documents (that is, documents that may contain links that allow navigation to other documents).

The abbreviation HTTP stands for HyperText Transfer Protocol, "hypertext transfer protocol". According to the OSI specification, HTTP is an application (upper, 7th) layer protocol. The current version of the protocol, HTTP 1.1, is described in the RFC 2616 specification.

The HTTP protocol involves the use of a client-server data transfer structure. The client application generates a request and sends it to the server, after which the server software processes the request, generates a response and sends it back to the client. The client application can then continue to send other requests, which will be processed in the same way.

A task that is traditionally solved using the HTTP protocol is the exchange of data between a user application that accesses web resources (usually a web browser) and a web server. At the moment, it is thanks to the HTTP protocol that the World Wide Web operates.

HTTP is also often used as a transport protocol for other application layer protocols such as SOAP, XML-RPC and WebDAV. In this case, the HTTP protocol is said to be used as a “transport”.

The API of many software products also implies the use of HTTP for data transfer - the data itself can be in any format, for example, XML or JSON.

Typically, HTTP data transfer is carried out over TCP/IP connections. In this case, server software usually uses TCP port 80 (and, if the port is not specified explicitly, then client software usually uses port 80 by default for opening HTTP connections), although it can use any other one.

How to send an HTTP request?

The easiest way to understand the HTTP protocol is to try to access some web resource manually. Imagine that you are a browser and you have a user who really wants to read articles by Anatoly Alizar.

Let's say he entered the following in the address bar:

Http://alizar.habrahabr.ru/

Accordingly, you, as a web browser, now need to connect to the web server at alizar.habrahabr.ru.

To do this, you can use any suitable command line utility. For example, telnet:

Telnet alizar.habrahabr.ru 80

Let me clarify right away that if you suddenly change your mind, press Ctrl + “]” and then enter - this will allow you to close the HTTP connection. In addition to telnet, you can try nc (or ncat) - depending on your taste.

After you connect to the server, you need to send an HTTP request. This, by the way, is very easy - HTTP requests can consist of just two lines.

In order to generate an HTTP request, you need to compose a starting line, and also set at least one header - this is the Host header, which is mandatory and must be present in every request. The fact is that the conversion of a domain name to an IP address is carried out on the client side, and, accordingly, when you open a TCP connection, the remote server does not have any information about which address was used for the connection: it could be, for example , address alizar.habrahabr.ru, habrahabr.ru or m.habrahabr.ru - and in all these cases the answer may differ. However, in fact, in all cases the network connection is opened with node 212.24.43.44, and even if initially when opening the connection it was not this IP address that was specified, but some domain name, the server is not informed about this in any way - and that is why this address is necessary pass in the Host header.

The starting (initial) request line for HTTP 1.1 is composed according to the following scheme:

For example (such a starting line may indicate that the main page of the site is being requested):

And, of course, don’t forget that any technology becomes much simpler and clearer when you actually start using it.

Good luck and fruitful learning!

Tags: Add tags