Consider this HTML:

Enter text:

Then the data will be sent using the GET method.

If, in the case of a GET request, the amount of data that we could transfer was limited by the length of the browser's address bar, then in the case of a POST request, there is no such limitation, and we can transfer significant amounts of information.

Another difference between the POST method and GET method, the POST method hides all the variables passed to it and their values ​​in its body (Entity-Body). In the case of the GET method, they were stored in the request string (Request-URI).

Here's an example of a POST request:

POST / HTTP / 1.0 \ r \ n
Host: www.site.ru \ r \ n
Referer: http://www.site.ru/index.html\r\n
Cookie: income = 1 \ r \ n
Content-Type: application / x-www-form-urlencoded \ r \ n
Content-Length: 35 \ r \ n
\ r \ n
login = Dima & password = 12345

Thus, by transmitting data using the POST method, it will be much more difficult for an attacker to intercept it, because they are hidden from view, so the POST method is considered safer.

In addition, the POST method can transfer not only text, but also multimedia data (pictures, audio, video). There is a special Content-Type parameter that determines the kind of information that needs to be transferred.

Finally, the POST variable is used to retrieve the data transmitted by this method on the server.

Here's an example of processing in PHP:

echo $ _POST [‘text’];
?>

In the last post, we 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 processed according to certain rules. There is, something like the syntax, how and in what sequence should be written. There must be a well-defined structure.

Let's take a closer look at this structure, which is used to build requests and responses in the HTTP protocol.

An HTTP request consists of three main parts, which come in exactly the order shown below. There is an empty line between the headers and the body of the message (as a separator), it is a line feed character.

Empty string (separator)

Post and Get requests, what's the difference between them and which is better and for what purposes?

message body (Entity Body) - optional parameter

Query string- specifies the transmission method, the URL to access, and the version of the HTTP protocol.

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

message body- this is the data itself, which is transmitted in the request. The message body is an optional parameter and can be omitted.

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.

In more detail, each element of the request, we will consider in the following notes.

Let's take one real server request as an example. I have highlighted each part of the request with its own color: the request line is green, the headers are orange, the body of the message is blue.

Request from browser:

Host: webgyry.info

Cookie: wp-settings

Connection: keep-alive

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

Server response:

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

Transfer-Encoding: chunked

Connection: keep-alive

Keep-Alive: timeout = 5

X-Pingback: //webgyry.info/xmlrpc.php

These are the messages that are exchanged between the client and the server over the HTTP protocol.

By the way, do you want to know if there is any sense in some element on your site using the "goals" of Yandex Metrics and Google Analytics?

Take away what does NOT work, add what works and double your bottom line.

A course on setting up Yandex Metrica goals ..

A course on setting up Google Analytics goals ..

The HTTP client sends a request to the server in the form of a request message, which has the following format:

• Request string (required)
• Title (optional element)
• Empty string (required)
• Message body (optional)

Let's take a look at each of these elements separately.

Query string

The request string begins with a method token, followed by the request URI and protocol version. Elements are separated from each other by spaces:

Let's consider this element in more detail.

Request method

This element specifies the method to be called on the server side on the specified URI.

There are eight methods in HTTP:

• HEAD
  Used to get the status line and title from the server by URI. Doesn't change data.
• GET
  Used to receive data from the server at the specified URI. Doesn't change data.
• POST
  Used to send data to the server (such as developer information, etc.) using HTML forms.
• PUT
  Replaces all previous data on the resource with the newly loaded data.
• DELETE
  Removes all current data on the resource specified by the URI.
• CONNECT
  Establishes a tunnel connection to the server at the specified URI.
• OPTIONS
  Describes the connection properties for the specified resource.
• TRACE
  Provides a message containing a back trace of the location of the specified resource URI.

Request URI

URI (Uniform Resource Identifier) ​​is the identifier of the resource to which the request is sent. The most common URI format is shown below:

‘*’ used when the HTTP request is not specific to a specific resource, but to a server. Used only when the method does not need to be applied to the resource. For instance,

absolute uri used when an HTTP request is made to a proxy. The proxy is requested to pass the request from the available cache and returns a response. For instance:

asbolutny_path | a source used by most chatso.

Learning to work with GET and POST requests

A specific resource of a specific server is requested. For example, a client wants to get a resource from the server through port 80. The resource address is “www.proselyte.net” and sends the following request:

Requesting header fields

Header fields allow the client to pass additional information about the request and about itself to the server. These fields act as request modifiers.

Below is a list of the most important header fields that can be used:

• Accept-Charset
• Accept-Encoding
• Accept-Language
• Authorization
• Expect
• If-Match
• If-Modified-Since
• If-None-Match
• If-Range
• If-Unmodified-Since
• Range
• Referer
• User-Agent

If we want to implement our own client and our own web server, then we can create our own header fields.

Example HTTP request

This concludes our study of HTTP requests.
In the next article, we'll look at HTTP responses.

One of the ways how you can send an HTTP request to the server is a GET request. This method is the most common and most often requests to the server are made using it.

The easiest way to create a GET request is to type the URL into your browser's address bar.

The browser will transmit the following information to the server:

GET / HTTP / 1.1
Host: webgyry.info
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

The request consists of two parts:

1. request line

2.headers (Message Headers)

Please note that the GET request does not have a message body. But, this does not mean that with its help we cannot transfer any information to the server.

Difference between GET and POST methods

This can be done using special GET parameters.

To add GET parameters to the request, you need to put a "?" Sign at the end of the URL. and after it, start asking them according to the following rule:

parameter_name1 = parameter_value1 & parameter_name2 = parameter_value2 & ...

The separator between the parameters is the "&" sign.

For example, if we want to pass two values ​​to the server, the username and his age, then this can be done with the following line:

http://site.ru/page.php?name=dima&age=27

When this query is executed, the data goes into the so-called QUERY_STRING environment variable, from which it can be retrieved on the server using the server-side web programming language.

Here's an example of how this can be done in PHP.

echo "Your name:". $ _GET ["name"]. "
»;
echo "Your age:". $ _GET ["age"]. "
»;
?>

The $ _GET ["parameter_name"] construct allows you to display the value of the passed parameter.

As a result of executing this code in the browser, the following will be displayed:

Your name: dima
Your age: 27

we also make a request to the server using the GET method.

This post is an answer to a question asked in a comment on one of my articles.

In this article, I want to tell you what the HTTP methods GET / POST / PUT / DELETE and others are, what they were invented for and how to use them in accordance with REST.

HTTP

This protocol describes communication between two computers (client and server), based on messages called Request and Response. Each message consists of three parts: a start line, headers, and a body. In this case, only the start line is required.

The starting lines for the request and response have a different format - we are only interested in the starting line of the request, which looks like this:

METHOD URI HTTP / VERSION ,

Where METHOD is just the HTTP request method, URI is the resource identifier, VERSION is the protocol version (version 1.1 is currently relevant).

Headers are a collection of name-value pairs, separated by colons. Various service information is transmitted in the headers: message encoding, browser name and version, address from which the client came (Referrer), and so on.

The body of the message is, in fact, the transmitted data. In the response, the transmitted data, as a rule, is the html page that the browser requested, and in the request, for example, in the body of the message, the content of the files uploaded to the server is transmitted. But as a rule, the body of the message is not included in the request at all.

Example HTTP communication

Inquiry:
GET /index.php HTTP / 1.1 Host: example.com User-Agent: Mozilla / 5.0 (X11; U; Linux i686; ru; rv: 1.9b5) Gecko / 2008050509 Firefox / 3.0b5 Accept: text / html Connection: close
The first line is the request line, the rest are headers; message body is missing

Answer:
HTTP / 1.0 200 OK Server: nginx / 0.6.31 Content-Language: ru Content-Type: text / html; charset = utf-8 Content-Length: 1234 Connection: close ... THE HTML PAGE ITSELF ...

Resources and methods

The HTTP request type (also called HTTP method) tells the server what action we want to take with the resource. Initially (in the early 90s) it was assumed that the client can only want one thing from the resource - to get it, but now, using the HTTP protocol, you can create posts, edit the profile, delete messages and much more. And these actions are difficult to combine with the term “receiving”.

To differentiate actions with resources at the level of HTTP methods, the following options were invented:

• GET - getting a resource
• POST - creating a resource
• PUT - resource update
• DELETE - deleting a resource

REST comes into play

REST proposes to abandon the use of the same URI for different resources (that is, the addresses of two different articles like /index.php?article_id=10 and /index.php?article_id=20 are not a REST-way) and use different HTTP methods for different action. That is, a web application written using the REST approach will delete a resource when accessing it with the HTTP DELETE method (of course, this does not mean that you should be able to delete everything and everything, but any the application's delete request must use the HTTP DELETE method).

REST gives programmers the ability to write standardized and slightly prettier web applications than ever before. Using REST, the URI to add a new user will not be /user.php?action=create (GET / POST method), but simply /user.php (strictly POST method).

As a result, by combining the existing HTTP specification and the REST approach, various HTTP methods finally make sense. GET - returns a resource, POST - creates a new one, PUT - updates an existing one, DELETE - deletes.

Problems?

PUT / DELETE requests can be sent via XMLHttpRequest, by contacting the server "manually" (say, via curl or even via telnet), but you cannot make an HTML form sending a full PUT / DELETE request.

The point is, the HTML specification does not allow you to create forms that submit data other than via GET or POST. Therefore, for normal operation with other methods, you have to imitate them artificially. For example, in Rack (the mechanism by which Ruby interacts with the web server; Rails, Merb and other Ruby frameworks are made using Rack), you can add a hidden field named "_method" to a form, and specify the name of the method as the value (for example, "PUT") - in this case, a POST request will be sent, but Rack will be able to pretend that it received a PUT, not a POST.

Currently, only two HTTP methods are most commonly used: GET and POST. But it turned out that even among these two "pines" web developers manage to get lost. There is an explanation for this: both methods can be used to get the same result. But it must be remembered that the ill-considered application of any of the methods can lead to disastrous consequences, including large loads on the channel and security holes.

To avoid this, it is enough just to understand in more detail the purpose and differences of these methods.

If you delve into the meaning of the names of the methods, a lot will become clear. GET (from English to receive), i.e. should be used to query data. POST (from English send by mail) - we use it to send data to the server. Everything seems to be extremely simple and understandable. But who wants to develop sites a little more complicated than a business card site with one feedback form, it is better to get to know the issue better.

Safe and insecure HTTP requests

The HTTP 1.1 specification introduces two concepts: a secure request and an insecure request, or more precisely, a method.

Safe methods are methods that can only request information. They cannot change the requested resource, they cannot lead to undesirable results for the user, other persons or the server. Examples of safe ones are requesting the HTML code of a web page or image. The safe methods are HEAD and GET.

The note

In reality, craftsmen of course can do harm with GET requests. For example, query loops.

Insecure queries, as everyone has already guessed, can potentially lead to bad consequences if they are reused. Such requests can change the content of the resource being accessed. Examples of such requests: sending messages, registering, online payments. The unsafe methods are POST, PUT, DELETE.

Idempotent methods

Idempotency is a property of methods that, with multiple repeated calls, will return the same result, unless the information is out of date. This means that when accessing the same URL, all users will see the same web page, image, video, etc. GET, PUT, DELETE methods have this property.

Now let's take a closer look at the GET and POST methods themselves: let's compose a short "summary" for each.

GET

• designed to receive data from the server;
• the request body is empty;
• are processed on the server side faster and with less consumption of server resources due to an empty request body;
• the transfer of variables occurs in the address bar (this is how the user sees it, technically the data is transferred in the query line) and therefore information about the variables and their values ​​is visible (the data is not protected);
• able to transfer a small amount of data to the server: there are restrictions on the length of the URL, which depends on the browser, for example IE6 = 2Kb. This is the number that the Yahoo! developers recommend targeting;
• can only transmit ASCII characters;
• such a request can be copied, saved (for example, in bookmarks);
• the request can be cached (this can be controlled);
• conditional and partial requests are available to further reduce the load on the channel and server;
• does not break the HTTP connection (when keepAlive mode is enabled on the server).

POST

• designed to send data to the server;
• data transfer occurs in the request body;
• server-side processing is slower and "heavier" than GET, because in addition to headers, you need to parse the request body;
• able to transfer large amounts of data;
• able to transfer files;
• the page generated by the POST method cannot be bookmarked;
• breaks the HTTP connection;
• to transfer even a very small amount of information, most browsers send at least two TCP packets: the header, and then the request body.

It turns out that these two methods are not so similar. The use of this or that should be determined by the task at hand, and not by the fact that GET is used by default or is easier to work with. GET is certainly a better option in most cases, especially when building fast AJAXs, but don't forget its drawbacks. For myself, I made a simple algorithm-note on the choice of the method.

This post is the answer to a question asked in one of my articles.

In this article, I want to tell you what the HTTP methods GET / POST / PUT / DELETE and others are, what they were invented for and how to use them in accordance with REST.

HTTP

This protocol describes communication between two computers (client and server), based on messages called Request and Response. Each message consists of three parts: a start line, headers, and a body. In this case, only the start line is required.

The starting lines for the request and response have a different format - we are only interested in the starting line of the request, which looks like this:

METHOD URI HTTP / VERSION ,

Where METHOD is just the HTTP request method, URI is the resource identifier, VERSION is the protocol version (version 1.1 is currently relevant).

Headers are a collection of name-value pairs, separated by colons. Various service information is transmitted in the headers: message encoding, browser name and version, address from which the client came (Referrer), and so on.

The body of the message is, in fact, the transmitted data. In the response, the transmitted data, as a rule, is the html page that the browser requested, and in the request, for example, in the body of the message, the content of the files uploaded to the server is transmitted. But as a rule, the body of the message is not included in the request at all.

Example HTTP communication

Inquiry:
GET /index.php HTTP / 1.1 Host: example.com User-Agent: Mozilla / 5.0 (X11; U; Linux i686; ru; rv: 1.9b5) Gecko / 2008050509 Firefox / 3.0b5 Accept: text / html Connection: close
The first line is the request line, the rest are headers; message body is missing

Answer:
HTTP / 1.0 200 OK Server: nginx / 0.6.31 Content-Language: ru Content-Type: text / html; charset = utf-8 Content-Length: 1234 Connection: close ... THE HTML PAGE ITSELF ...

Resources and methods

The HTTP request type (also called HTTP method) tells the server what action we want to take with the resource. Initially (in the early 90s) it was assumed that the client can only want one thing from the resource - to get it, but now, using the HTTP protocol, you can create posts, edit the profile, delete messages and much more. And these actions are difficult to combine with the term “receiving”.

To differentiate actions with resources at the level of HTTP methods, the following options were invented:

• GET - getting a resource
• POST - creating a resource
• PUT - resource update
• DELETE - deleting a resource

REST comes into play

REST proposes to abandon the use of the same URI for different resources (that is, the addresses of two different articles like /index.php?article_id=10 and /index.php?article_id=20 are not a REST-way) and use different HTTP methods for different action. That is, a web application written using the REST approach will delete a resource when accessing it with the HTTP DELETE method (of course, this does not mean that you should be able to delete everything and everything, but any the application's delete request must use the HTTP DELETE method).

REST gives programmers the ability to write standardized and slightly prettier web applications than ever before. Using REST, the URI to add a new user will not be /user.php?action=create (GET / POST method), but simply /user.php (strictly POST method).

As a result, by combining the existing HTTP specification and the REST approach, various HTTP methods finally make sense. GET - returns a resource, POST - creates a new one, PUT - updates an existing one, DELETE - deletes.

Problems?

PUT / DELETE requests can be sent via XMLHttpRequest, by contacting the server "manually" (say, via curl or even via telnet), but you cannot make an HTML form sending a full PUT / DELETE request.

The point is, the HTML specification does not allow you to create forms that submit data other than via GET or POST. Therefore, for normal operation with other methods, you have to imitate them artificially. For example, in Rack (the mechanism by which Ruby interacts with the web server; Rails, Merb and other Ruby frameworks are made using Rack), you can add a hidden field named "_method" to a form, and specify the name of the method as the value (for example, "PUT") - in this case, a POST request will be sent, but Rack will be able to pretend that it received a PUT, not a POST.

You may have noticed that on most sites you can see the following addresses:

Http: //site/index.php? Blog = 2

Here, even without knowing php, you can guess that we are referring to the file index.php But few people know what comes after the question mark. It's pretty simple: ? blog = 2 this is the declaration of the global variable "$ _GET [" blog "]" with the value "2". Thus, I pass a variable to the script that is responsible for displaying information from the database. Let's write a small script in which you will clearly see everything:

if (isset ($ _ GET ["blog"])) (
echo $ _GET ["blog"];
}
?>

We use the condition statement if () as the condition is the following line:

Isset ($ _ GET ["blog"])

isset () allows you to find out if the variable that is specified in brackets exists, that is, the condition that I described in the code sounds like this: If the variable $ _GET ["blog"] exists, then display the contents of this variable on the screen. Here's what happened:

I think it's clear A global variable is being created $ _GET with the identifier that we declared in the address bar ( in this case with the identifier "blog")

Now I want to clarify one point. Suppose we need to declare two variables, how do we do this? The first variable is declared after the question mark "?" The second variable is declared after such a "&" ( To be honest, I don't know what this sign is), here's an example of declaring three variables:

Http: //site/index.php? A = 1 & b = 2 & c = 3

Here is the output code:

if (isset ($ _ GET ["a"]) AND isset ($ _ GET ["b"]) AND isset ($ _ GET ["c"])) (
echo $ _GET ["a"]. "
";
echo $ _GET ["b"]. "
";
echo $ _GET ["c"]. "
";
}
?>

The condition goes like this:

If there is a global variable $ _GET ["a"] and a global variable $ _GET ["b"] and a global variable $ _GET ["c"] then display them, here is the result:

Forms

Before we get to post queries, you need to understand what forms are? Why is it necessary? Because the global variable $ _POST [""] is created through the forms. What is a form? These are fields for entering some kind of information by the user. Fields are in one line, large fields, there are also radio buttons, check boxes. Let's sort everything out in order ...

Form is a tag:

form elements

Your Surname First Name Patronymic:

Your gender:
M
F

What country are you from

Russia
Other country

Favorite color (s):

Black:
Red:
White:
Another:

About myself:

Note that almost every tag has an attribute value, what is it for? It records the data that you are going to transfer to another page. I hope it is clear

Now if we run this code in a browser, we will see the following:

I used the attribute for the form action with the meaning test.php this means, as I said, the data from the form will be passed to the test.php file.

POST request

Now let's write php code that will allow us to see the information we entered. Where is the data stored? In the case of the get request, our data was stored in the global variable $ _GET [""]. When a post request is made, the data will be in the global variable $ _POST [""]. In square brackets, you must write the identifier, as in the case with the global variable get. The question is, where can I get this identifier? That's why we need the name attribute on form elements! It is these names that serve as a key for us in the global array post. Well, let's start describing the script:

if (isset ($ _ POST ["submit"])) (
echo "Name:". $ _ POST ["fio"]. "
";
echo "Sex:". $ _ POST ["sex"]. "
";
echo "Country of residence:". $ _ POST ["city"]. "
";

Echo "Favorite color (s):
";
echo $ _POST ["color_1"]. "
";
echo $ _POST ["color_2"]. "
";
echo $ _POST ["color_3"]. "
";
echo $ _POST ["color_4"]. "
";
echo "About me:". $ _ POST ["about"]. "


";
}
?>

The if condition we have written says: If there is a global variable $ _POST ["submit"], then we display the data on the screen. This global variable is created if we clicked on the submit button, which is why in this example we need the name attribute in the button. You may well be wondering why the name attribute is optional for the button? It's pretty simple. Usually the programmer does not track the pressing of the button, but tracks the data sent. For the correct operation of, for example, contact forms, it is necessary to track not the pressing of a button, but the correctness of the information entered, and find out whether this information was entered at all. In our example, we did not check the sent data, but simply tracked the button click, to simplify the example ... Here's what we got:

Conclusion

Well, today we have analyzed two methods of transferring data between scripts, as well as gallops got acquainted with forms. I really hope that this information will be useful to you at least somewhere. If you have any questions or thoughts, write comments. Good luck, I have everything for today!

PS: Do you want computer games to become even more realistic? Directx 11 for windows 7 can be downloaded for free on Windows in! Enjoy great graphics!