Рубрика «http» - 10

Один из аспектов понятия «производительность Web» заключается в том, чтобы уменьшить наблюдаемые пользователем задержки; получить готовую к работе страницу как можно быстрее. В отношении протокола HTTP это подразумевает, что идеальный протокол связи выглядит как-то так:

Идеальная производительность протокола HTTP - 1

Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправкиприёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.

Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?
Читать полностью »

Желание разработать собственный Angular.js webApi модуль возникло при работе с большим количеством http-запросов в проекте.

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

Задачи, которые должен решать будущий webApi модуль:

  1. Предотвратить дублирование http-запросов в проекте.
  2. Группировать существующий список запросов по функциональным категориям, чтобы проще вносить правки в конкретные методы.
  3. Быть полностью независимой функциональной единицей приложения, которая подключается к любому другому Angular.js проекту простым Dependency Injection'ом.
  4. Инкапсулировать внутреннюю реализацию, чтобы избежать проблем при работе с внешними источниками.

Дальше поговорим о каждом из этих пунктов подробнее.Читать полностью »

В далёком 2012 на Хабре обсуждались «рестриктеры», «делитеры», «цензурасты», а также «абузо-устойчивые» провайдеры в статье про то, что был предложен новый HTTP-статус для цензуры, а точнее для ресурсов, доступ к которым ограничен из-за проблем с законом.

Собственно статус HTTP 451 был предложен Тимом Брэйем из Google, а виновником (в прямом и переносном смысле) переполоха стал в очередной раз заблокированный, заабузенный, зацензуренный и великий The Pirate Bay.

Почему это важно? Потому что вы, наверное, как и я, пользуетесь GitHub, программируете не только для души и, возможно, владеете доходными интернет-ресурсами.

Вы уже находитесь в правовом поле авторского права.
Читать полностью »

HTTP/2

В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP — HTTP/2. HTTP/2 уже поддерживается в популярных веб-серверах: Apache и Nginx. Идёт работа по внедрению HTTP/2 в IIS. Реализована поддержка и в большинстве современных браузеров.

Использование HTTP/2 за последнее время существенно расширилось.
Читать полностью »

Давайте рассмотрим создание минимального HTTP API Endpoint используя Elixir. Так же, как и Rack в Ruby, Elixir идет в комплекте с Plug. Это универсальный инструмент для работы с HTTP соединениями.

Минимальный HTTP API Endpoint используя Elixir - 1Читать полностью »

Шифрование. Мы все его любим и хотим использовать везде. Но почему оно до сих пор не применяется повсеместно?

Проблема в сертификатах?

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

Большинство предложений перехода на повсеместное шифрование звучат примерно так: «NSA записывает весь наш трафик, почему бы не шифровать его?». Целью подобных предложений является повышение стоимости пассивного слежения за всем трафиком, а не более сложные и целевые атаки, которые применяются злоумышленниками.

Ребята из Let's Encrypt уже догадались, что проблема с сертификатами почти полностью поддаётся автоматизации, и что её реализация для выпуска, установки, конфигурации и продления на нескольких наиболее распространённых платформах может покрыть подавляющее большинство Интернета. Замечательная работа, и, хоть и осталось сделать многое, я думаю, что мы можем считать проблему сертификатов решённой.
Читать полностью »

А ваше приложение — RESTful? Чтобы ответить на этот вопрос нужно сначала разобраться что такое RESTful. Бытует мнение, что отдавать правильные коды ответов в HTTP — это уже RESTful. Или делать правильные идемпотентные HTTP-запросы — это вообще очень RESTful. Мы в Хекслете сделали практический курс по протоколу HTTP (отличия версий, отправка форм, аутентификация, куки и пр.), и в нем мы стараемся рассказать о правильном использовании запросов, но нужно понимать, что RESTful это не про HTTP, это вообще не про протоколы интернета. Современный веб и взаимодействие между браузером и сервером с помощью HTTP и URI могут удовлетворять принципам RESTful, а могут и не удовлетворять.

В сегодняшнем переводе — простое и понятное описание RESTful, и какой должна быть система, чтобы ее можно было так называть.

Что такое RESTful на самом деле - 1Читать полностью »

image

Инженерный совет Интернета (Internet Engineering Task Force, IETF) одобрил новый код статуса HTTP: "451 Unavailable for Legal Reasons". Он будет выдаваться в ответ на запросы к сайтам, заблокированным по запросам властей, связанным с политическими вопросами, нарушениями авторских прав и т.д. Код получил свой номер в честь известного фантастического произведения Рэя Бредбери «451 градус по Фаренгейту».

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

Естественно, каждый провайдер выполняет эти предписания по-своему, в связи с чем и назрело появление нового стандарта. Провайдеры не обязаны подчиняться решениям IETF, но использование стандартов обычно идёт на пользу системе.

Существует проект 451unavailable.org, целью которого является пропаганда использования нового HTTP-статуса. Его основатели рекомендуют выкладывать в публичный доступ судебные решения, послужившие причиной блокировок, чтобы общественность была лучше информирована о происходящем, а не просто получала непонятное сообщение об отсутствии доступа «403 forbidden».
Читать полностью »

Атака по времени на HSTS Sniffly показывает, на какие сайты ходил пользователь - 1Современные браузеры поддерживают функцию HTTP Strict Transport Security (HSTS). Флаг HSTS показывает, что с определённого домена нужно запрашивать шифрованную HTTPS-версию — даже если переход осуществляется по HTTP, а не HTTPS. Механизм нужен для обеспечения дополнительного уровня безопасности: браузер мог бы запросить HTTP-версию страницы, которую легко прослушать или подменить. Так можно избежать некоторых атак с понижением уровня защиты и перехват куки.

Данные, что у конкретного домена был установленный флаг HSTS, сохраняются в браузере пользователя. Это логическая переменная (true/false). Это не куки-файлы, а информация о безопасности, поэтому браузеры относятся к ней иначе. О слежении с помощью куки хорошо известно. Пользователь может зайти в настройки браузера и удалить те куки, которые ему не нравятся. Есть отдельные дополнения, которые запрещают приём куки от доменов маркетинговых компаний. Очистка настроек HSTS не так прозрачна — в браузерах можно удалить лишь все флаги для всех сайтов сразу. В январе Сэм Гринхал продемонстрировал, что с помощью HSTS можно создать суперкуки, которые не так легко удалить.

В прошлом месяце Янь Чжу показала на конференции ToorCon в Сан-Диего Sniffly. Проект использует HSTS и Content Security Policy для того, чтобы определить, какие сайты из списка пользователь уже посетил.
Читать полностью »

На днях мы выпустили Coub API. Теперь можно делать приложения, смотреть ленту, лайкать, рекобить, то есть практически все, что можно сделать на сайте, можно делать через API. Но самое главное — теперь можно из сторонних приложений через API создавать кобы.

В этом туториале я покажу, как можно сделать простейший клиент коба на Ruby on Rails. Приложение позволяет залогиниться через коб и сгенерить такой коб с любым текстом:

Рабочая версия этого приложения лежит по адресу fantozzi.dev2.workisfun.ru, код приложения из этого туториала можно посмотреть на Гитхабе: github.com/igorgladkoborodov/memegenerator
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js