Лидеры

Хм. Действительно, в RFC7230 валидный Content-Length — любое целочисленное неотрицательное значение. Попытался найти, почему я решил, что нельзя слать больше, чем в Content-Length, и обнаружил следующее в устаревшей версии стандарта: — RFC2616: “Hypertext Transfer Protocol -- HTTP/1.1”, §4.4, стр. 34 Что, в принципе, объясняет мою уверенность. В таком случае, действительно, стоит ориентироваться на Content-Length. Статью исправлю соответствующе. Спасибо за замечания.

Пролистал RFC7230. Как ни странно, не нашёл там указаний на то, что после отправки сообщения сервер не может по тому же соединению отправлять ещё бессмысленный мусор. А если Content-Length меньше длины полученных данных, то не указано, корректный это заголовок или нет. А вообще, получается так: если сервер, например, решит "а я не буду закрывать соединение после отправки сообщения", то программа будет висеть, пока это соединение не разорвётся чем-нибудь посередине. Плюс сервер (доверять которому обычно не надо бы) может заставить программу на Lua использовать произвольное количество памяти. Не совсем best practices, по-моему

Потрясающее замечание. Отвечу развёрнуто с удовольствием. Если посмотреть на код, то можно заметить, что я эту проблему опознал и в случае несоответствия в меньшую сторону я решил хедер игнорировать (собственно, поэтому в сравнении там оператор >=). К сожалению, когда код я стал комментировать, про это совершенно забыл — и без этого коммента бы, наверное, и не вспомнил. Претензия имеет силу, если мы обратимся к стандарту. Юзер-агент должен в случае получения невалидного хедера Content-Length просигналить об ошибке и выбросить полученные данные: — RFC7230: “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, §3.3.3, стр. 32–33 Более того, когда писал код, специально стандарт вычитывал именно поэтому. Почему же тогда в статье я решил игнорировать его предписания, притом намеренно? Для простоты. Чтобы не вдаваться в детали HTTP, не рассказывать про Transfer-Encoding и не требовать реализации алгоритма из цитированного стандарта. Чтобы быть предельно педантным, нужно сначала проверить, не стоит ли Transfer-Encoding (потому что иначе длина неизвестна), потом убедиться, что все Content-Length имеют одно и то же значение (это тоже в статье я не освещал, но требуется стандартом), а затем читать данное число байт: если фактически пришло меньше или больше, ответ отбросить и вернуть ошибку. Или же подойти с прагматической стороны, учесть, что по соединению из OC мы можем отправить ровно один HTTP-запрос и забить на эту сложность. Возможно, стоит проверить, что Content-Length все имеют согласованное значение и являются интами, чтобы быть уверенным в ожидаемой длине. Самое главное, что требуется от того кода: убедиться, что соединение не порвалось посередине ответа. Поэтому, хотя всех тонкостей HTTP я действительно не знаю, я бы не спешил декрементить счётчик. :P

Уменьшаем счётчик на единицу. Претензия к пункту 3.3. Программа читает столько данных, сколько может - если сервер укажет маленький Content-Length и отправит гигабайт данных, программа всё это будет читать.

Вообще, из наличия в статье пятого пункта уже следует, что с обёртками я знаком и в путешествии к докам не нуждаюсь. Поэтому буду считать, что этот комментарий не ко мне обращён. Тем не менее, обе функции бесполезны, кроме примитивных случаев. internet.request не ждёт соединения с сервером. Хотя она прокидывает ошибки через error, этого недостаточно. См. 3.2–3.4 про то, как правильно послать запрос и получить ответ. А с таким кодом смысла в использовании обёртки ноль. internet.open кладёт оригинальный сокет в приватные свойства. Заставляет программиста постоянно и без причины дёргать :read() и не даёт воспользоваться сигналом internet_ready. Поэтому не только бесполезен, но и вреден. Нужно вызывать internet.socket, чтобы можно было получить id сокета и вызвать finishConnect, и вручную класть стрим в буфер. См. 4.5–4.8 про то, как правильно создать и использовать сокет. Таким образом, действительно полезна только одна функция — internet.socket. И очень зря она не удостоилась такой характеризации цитируемым комментарием.