Как работает интернет

DNS

• Когда пользователь запускает веб-браузер и вводит название домена сайта, его ПК отправляет запрос к DNS-серверу интернет-провайдера для получения IP-адреса, на котором находится домен.
• Если DNS-серверы провайдера не обнаруживают в своем кэше информации о запрашиваемом сайте, то отправляют запрос на корневые DNS-серверы.
• Корневой DNS-сервер ищет в своей базе данных информацию о серверах имен хостинг-провайдера, на которых присутствует этот сайт. Далее, он сообщает их кэширующему DNS-серверу провайдера.
• После того, как кэширующий DNS-сервер интернет-провайдера получает информацию о серверах имен хостинг-провайдера он опрашивает любой из них и, в случае получения положительного результата получения IP-адреса, помещает в кэш. Кэширование используется для того, чтобы снизить как нагрузку на интернет-каналы, так и для ускорения получения результата запроса.
• После этого DNS-сервер провайдера передает IP-адрес браузеру пользователя, совершившему запрос сайта.
• И уже после этого браузер, получив IP-адрес запрашиваемого сайта, переходит на сам сайт.

HTTP запросы

HTTP клиент (браузер) посылает запрос на сервер в форме cсообщения-запроса, которое имеет следующий формат:

• Строка запроса (обязательный элемент)
• Заголовок (опционалный элемент)
• Пустая строка (обязательный элемент)
• Тело сообщения (опциональный элемент)

Рассмотрим каждый из этих элементов по отдельности.

Строка запроса

Строка запроса начинается с токена метода, после которого следует URI запроса и версия протокола. Элементы отедляются друг от друга пробелами:

Строка-запроса = Метод (пробел) URI запроса (пробел) версия-HTTP (следующая строка)

Расмотрим данный элемент более подробно

Метод запроса

Данный элемент указывает метод, который должен быть вызван на стороне сервера по указанному индентификатору URI.

В HTTP существует восемь методов:

• HEAD
• Используется для получения строки статуса и заголовка от сервера по URI. Не изменяет данные.
• GET
• Используется для получения данных от сервера по указанному URI. Не изменяет данные.
• POST
• Используется для отправки данных на сервер (например информации о разработчике и т.д.) с помощью форм HTML.
• PUT
• Замещает все предыдущие данные на ресурсе новыми загруженными данными.
• DELETE
• Удаляет все текущие данные на ресурсе, определённом URI.
• CONNECT
• Устанавливает туннельное соединение с сервером по указанному URI.
• OPTIONS
• Описывает свойства соединения для указанного ресурса.
• TRACE
• Предоставляет сообщение, содержащее обратный трейс расположения указанного в URI ресурса.

URI запроса

URI (Uniform Resource Identifier) – это идентификатор ресурса на который отправляется запрос. Ниже приведён наиболее часто встречающийся формат URI:

URI-запроса = "*" | абсолютныйURI | абсолютный_путь | источник

‘*’ используется когда HTTP запрос не относится к конкретному ресурсу, но к серверу. Используется только в случае, когда метод не обязательно применять к ресурсу. Например,

OPTIONS * HTTP/1.1

абсолютныйURI используется, когда HTTP запрос выполняется на прокси. Прокси запрашивается для передачи запроса из доступного кэша и возвращает ответ. Например:

GET https://www.proselyte.net/tutorials HTTP/1.1

асболютный_путь | источник используется наиболее чатсо. Запрашивается конкретный ресурс определённого сервера. Например, клиент хочет получить ресурс с сервера через 80-й порт. Адрес ресурса “www.proselyte.net” и отправляет следующий запрос:

GET /tutorials HTTP/1.1

Host: www.proselyte.net

Запрос полей заголовка

Поля заголовка позволяют клиенту передать дополнительную информацию о запросе и о себе самом серверу. Эти поля действуют как модификаторы запроса.

Ниже приведён списко наиболее важных полей заголовка, которые могут быть использованы:

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

Если мы захотим реализовать своего собственного клиента и свой собственный веб-сервер, то мы можем создавать собственные поля заголовка.

Пример HTTP запроса

GET /tutorials HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.proselyte.net
Accept-Language: ru-Ru
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

HTTP ответы

После получения и обработки запроса от клиента, сервер посылает ответ в виде HTTP сообщения, которое имеет вид:

• Строка статуса (обязательный элемент)
• Заголовок (опциональный элемент)
• Пустая строка (указывает на окончание заголовка – обязательный элемент)
• Тело сообщения (опциональный элемент)

Рассмотрим каждый из этих элементов по отдельности.

Строка статуса

Строка статуса содержит версию протокола, код статуса и текстовое сообщение, связанное с этим статусом

Строка-статуса = Версия-HTTP (пробел) Код-статуса (пробел) Текстовое-сообщение

Версия HTTP

Если сервер поддердивает версию прокотола HTTP 1.1, то мы получим следующий элемент Версия-HTTP:

Версия-HTTP = HTTP/1.1

Код статуса

Код статуса – это число, состоящее из тёрх цифр, первая из которых определяет тип ответа, а две послеюущие цифры указывают конкретную ошибку.

№Код и описание11xx: ИнформационноеОзначает, что запрос был успешно получен и идёт его обработка.

22xx: Успешное выполнение

Запрос был успешно получен, понят и принят.33xx: Перенаправление Последующие действия должны быть предприняты для выполнения запроса.44xx: Ошибка на стороне клиентЗапрос содержит синтаксическую ошибку, либо не корректен.

55xx: Ошибка на стороне сервера

Сервер не может выполнить обработать корректный запрос.Приложения, использующие HTTP не долдны понимать занчение всех кодов статуса. Полный список статусов приведён в отдельной статье цикла, посвящённого HTTP.

Поля заголовка ответа

Позже мы более подробно и отдельно рассмотрим заголовки General и Entity, а сейчас мы разберемся, что из себя представляют поля заголовка ответа, в общих чертах.

Поля заголовка ответа позволяют серверу предать дополнительную информацию об ответе, которая не может быть помещена в строке состояния. Эти поля дают информацию о сервере и последующем лоступе к ресурсам по указанному URI запроса:

• Accept-Ranges
• Age
• ETag
• Location
• Proxy-Authenticate
• Retry-After
• Server
• Vary
• WWW-Authenticate

Если мы хотим написать свои собственные веб-сервер и веб-клиент, мы можем создавать собственные поля.

Пример HTTP ответа

Ниже приведён пример HTTP ответа для несуществующей страницы nullpage.html на сайте proselyte.net

HTTP/1.1 404 Not Found
Date: Mon, 23 May 2016 13:49:49 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1


<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /nullpage.html was not found on this server.</p>
</body>
</html>

Коды статусов HTTP

Код состояния HTTP (англ. HTTP status code) — код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Пример:

403 Access allowed only for registered users

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

В настоящее время выделено пять классов кодов состояния:

• 1xx: Informational (русск. Информационный) — запрос получен и понят, а обработка продолжается.
• 2xx: Success (русск. Успешно) — запрос был успешно получен, понят и обработан.
• 3xx: Redirection (русск. Перенаправление) — для выполнения запроса должны быть предприняты дальнейшие действия.
• 4xx: Client Error (русск. Ошибка клиента) — запрос имеет плохой синтаксис или не может быть выполнен.
• 5xx: Server Error (русск. Ошибка сервера) — сервер не в состоянии выполнить допустимый запрос.

Ниже, представлены коды ответа из реестра кодов состояния IANA.

1xx: Informational

В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100 Continue
(русск. Продолжать)
Сервер удовлетворён начальными сведениями о запросе. Клиент может продолжать пересылать заголовки.

101 Switching Protocols
(русск. Переключение протоколов)
Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

102 Processing
(русск. Идёт обработка)
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.

2xx: Success

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

200 OK
(русск. Хорошо)
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

201 Created
(русск. Создано)
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.

202 Accepted
(русск. Принято)
Запрос был принят на обработку, но обработка не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс.

203 Non-Authoritative Information
(русск. Неавторитетная информация)
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

204 No Content
(русск. Нет содержимого)
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.

205 Reset Content
(русск. Сбросить содержимое)
Сервер обязывает клиента спросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.

206 Partial Content
(русск. Частичное содержимое)
Сервер удачно выполнил запрос клиента, но передал только часть документа. Такой ответ сервер может отправить если в заголовке запроса клиента есть поле Content-Range. Особое внимание при работе с подобными ответами следует уделить кэшированию.

207 Multi-Status
(русск. Многостатусный)
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с единственным объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.

226 IM Used
(русск. IM использовано)
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.

3xx: Redirection

Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).

Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.

300 Multiple Choices
(русск. Несколько выборов)
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту или пользователю.

301 Moved Permanently
(русск. Перемещёно окончательно)
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.

302 Found
(русск. Найдено)
Запрошенный документ был временно перенесен на другой URI, указанный в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.

303 See Other
(русск. Смотреть другое)
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET не смотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304 Not Modified
(русск. Не изменено)
Сервер возвращает такой код, если клиент запросил документ методом GET, в заголовке использовал поле Date и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305 Use Proxy
(русск. Использовать прокси)
Запрос к запрашиваемому ресурсе должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306 (Reserved)
(русск. Зарезервировано)
Использовалось раньше. В настоящий момент зарезервировано.

307 Temporary Redirect
(русск. Временное перенаправление)
Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400 Bad Request
(русск. Плохой запрос)
Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

401 Unauthorized
(русск. Неавторизован)
Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402 Payment Required
(русск. Необходима оплата (зарезервировано))
Предполагается использовать в будущем. В настоящий момент не используется.

403 Forbidden
(русск. Запрещено)
Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.

404 Not Found
(русск. Не найдено)
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

405 Method Not Allowed
(русск. Метод не поддерживается)
Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.

406 Not Acceptable
(русск. Не приемлемо)
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407 Proxy Authentication Required
(русск. Необходима авторизация прокси)
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.

408 Request Timeout
(русск. Время ожидания истекло)
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.

409 Conflict
(русск. Конфликт)
Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone
(русск. Удалён)
Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411 Length Required
(русск. Необходима длина)
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412 Precondition Failed
(русск. Условие «ложно»)
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413 Request Entity Too Large
(русск. Запрашиваемые данные слишком большие)
Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

414 Request-URI Too Long
(русск. Запрашиваемый URI слишком длинный)
Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type
(русск. Неподдерживаемый тип данных)
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416 Requested Range Not Satisfiable
(русск. Запрашиваемый диапазон не достижим)
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417 Expectation Failed
(русск. Ожидаемое ошибочно)
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422 Unprocessable Entity
(русск. Необрабатываемый экзмепляр)
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.

423 Locked
(русск. Заблокировано)
Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

424 Failed Dependency
(русск. Невыполненная зависимость)
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.

426 Upgrade Required
(русск. Необходимо обновление)
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

5xx: Server Error

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500 Internal Server Error
(русск. Внутренняя ошибка сервера)
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501 Not Implemented
(русск. Не выполнимо)
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.

502 Bad Gateway
(русск. Плохой шлюз)
Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.

503 Service Unavailable
(русск. Сервис недоступен)
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504 Gateway Timeout
(русск. Шлюз не отвечает)
Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505 HTTP Version Not Supported
(русск. Версия HTTP не поддерживается)
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506 Variant Also Negotiates (Experimental)
(русск. Вариант тоже согласован (экспериметальное))
В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.

507 Insufficient Storage
(русск. Закончилось место)
Не хватает места для выполнения текущего запроса. Проблема может быть временной.

510 Not Extended
(русск. Не расширено)
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

Cookie

Куки – это небольшие строки данных, которые хранятся непосредственно в браузере. Они являются частью HTTP-протокола, определённого в спецификации RFC 6265.

Куки обычно устанавливаются веб-сервером при помощи заголовка Set-Cookie. Затем браузер будет автоматически добавлять их в (почти) каждый запрос на тот же домен при помощи заголовка Cookie.

Один из наиболее частых случаев использования куки – это аутентификация:

1. При входе на сайт сервер отсылает в ответ HTTP-заголовок Set-Cookie для того, чтобы установить куки со специальным уникальным идентификатором сессии («session identifier»).
2. Во время следующего запроса к этому же домену браузер посылает на сервер HTTP-заголовок Cookie.
3. Таким образом, сервер понимает, кто сделал запрос.

Мы также можем получить доступ к куки непосредственно из браузера, используя свойство document.cookie.

LocalStorage, sessionStorage

Объекты веб-хранилища localStorage и sessionStorage позволяют хранить пары ключ/значение в браузере.

Что в них важно – данные, которые в них записаны, сохраняются после обновления страницы (в случае sessionStorage) и даже после перезапуска браузера (при использовании localStorage). Скоро мы это увидим.

Но ведь у нас уже есть куки. Зачем тогда эти объекты?

• В отличие от куки, объекты веб-хранилища не отправляются на сервер при каждом запросе. Поэтому мы можем хранить гораздо больше данных. Большинство браузеров могут сохранить как минимум 2 мегабайта данных (или больше), и этот размер можно поменять в настройках.
• Ещё одно отличие от куки – сервер не может манипулировать объектами хранилища через HTTP-заголовки. Всё делается при помощи JavaScript.
• Хранилище привязано к источнику (домен/протокол/порт). Это значит, что разные протоколы или поддомены определяют разные объекты хранилища, и они не могут получить доступ к данным друг друга.

Общение между окнами

Политика «Одинакового источника» (Same Origin) ограничивает доступ окон и фреймов друг к другу.

Идея заключается в том, что если у пользователя открыто две страницы: john-smith.com и gmail.com, то у скрипта со страницы john-smith.com не будет возможности прочитать письма из gmail.com. Таким образом, задача политики «Одинакового источника» – защитить данные пользователя от возможной кражи.

Политика "Одинакового источника"

Два URL имеют «одинаковый источник» в том случае, если они имеют совпадающие протокол, домен и порт.

Эти URL имеют одинаковый источник:

• http://site.com
• http://site.com/
• http://site.com/my/page.html

А эти – разные источники:

• http://www.site.com (другой домен: www. важен)
• http://site.org (другой домен: .org важен)
• https://site.com (другой протокол: https)
• http://site.com:8080 (другой порт: 8080)

Политика «Одинакового источника» говорит, что:

• если у нас есть ссылка на другой объект window, например, на всплывающее окно, созданное с помощью window.open или на window из <iframe> и у этого окна тот же источник, то к нему будет полный доступ.
• в противном случае, если у него другой источник, мы не сможем обращаться к его переменным, объекту document и так далее. Единственное исключение – объект location: его можно изменять (таким образом перенаправляя пользователя). Но нельзя читать location (нельзя узнать, где находится пользователь, чтобы не было никаких утечек информации).

Доступ к содержимому ифрейма

Внутри <iframe> находится по сути отдельное окно, то у окно, с собственными объектами documentи window.

Мы можем обращаться к ним, используя свойства:

• iframe.contentWindow ссылка на объект window внутри <iframe>.
• iframe.contentDocument – ссылка на объект document внутри <iframe>, короткая запись для iframe.contentWindow.document.

Когда мы обращаемся к встроенному в ифрейм окну, браузер проверяет, имеет ли ифрейм тот же источник. Если это не так, тогда доступ будет запрещён (разрешена лишь запись в location, это исключение).