Pull to refresh

Comments 23

«Мы собрали на руках карт-бланш» — когда хотелось выпендриться, но получилось только опозориться.
Материал интересный, зачем так язвить?
мда, такое количество людей не знает что такое «карт-бланш». и как он «собирается».
За полгода вы так и не поняли что высокомерный тон здесь ни к месту

В идеале бы не ссылаться на устаревший RFC (в новом, насколько я помню, плюс-минус тоже самое, но).

Материал действительно интересный, но у «кард-бланш» значение несколько другое, проверьте ;).
Спасибо, заменил на более подходящее по смыслу выражение.
UFO landed and left these words here
Пока еще думаем как с этим жить дальше и к кому можно уйти.
Дешевле разрабатывать собственный кривой сервер, чем взять открытый и бесплатный??

Поддержу Highwinds в данном споре. Chunked encoding совсем не для того, как вы его используете — он для случаев, когда на стороне источника потока данных есть какая-то относительно сложная логика, данных много и заранее неизвестно, когда они закончатся. Тело запроса к cdn — определённо не тот случай.

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

Да, и это не обязательно должен быть сервер, это может быть и клиент. И в спецификации HTTP сказано, что этот функционал должен быть реализован.

Да, может быть и клиент. Но (может я конечно не так понял?) в вашем случае нет множества данных которые неизвестно когда закончатся, а есть короткий запрос.
Зачем вот слать вот такое:


Transfer-Encoding: chunked\r\n\r\n
4\r\ndata\r\n
4\r\ntest\r\n
0\r\n\r\n

Когда можно послать так:


Content-Length: 8\r\n\r\n
datatest

.


Отдельно хочу заметить, что проблема не возникла, если бы Highwinds использовали любую Open Source реализацию HTTP сервера, например Varnish или Nginx, а не писали свою

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

Ну это всего лишь тестовый скрипт. В Android приложении, как я понимаю дело было в том, что программисты отправляли в http клиент данные через stream buffer, а он отправлял данные чанками по мере получения.
А вы рассматривайте CDN как не поддерживающую POST-запросы вообще. Спецификация HTTP это не запрещает :-)
К сожалению не получится. Когда подключали cdn проводили тестирование скорости и получился следующий топ (от самого быстрого к медленному, замеряли время dom ready на клиентах):
1) Статика на основном домене через CDN
2) Статика на основном домене без CDN
3) Статика на отдельном домене через CDN
4) Статика на отдельном домене без CDN
То есть использовать CDN есть смысл только в 1 случае, когда через cdn проксируется весь трафик сайта, а статика лежит на том же домене. Работать в таком режиме без POST запросов естественно нельзя. Вообще тема достаточно большая и если интересно могу написать отдельную статью о том, как мы это замеряли и к каким выводам пришли. ;)

Очень странно, что у вас статика на отдельном домене медленнее.
Я бы вам рекомендовал найти причину этого, т.к. обычно ситуация ровно обратная.
Может у вас для разных доменов разные ssl сертификаты (ну и 2 https соединения установить дольше, чем одно)?


Вообще, заводя логику через CDN, вы расставляете очень много грабель.
А если те ребята так обращаются, с RFC…
Вы бы узнали, например, как они обрабатывают другие заголовки, например Cache-Control.

Да, у нас есть своя специфика. Во первых сайт довольно легкий, страница весит около 500 кб, то есть она грузится достаточно быстро и дополнительный tcp+ssl хендшейк на отдельный домен тратит больше времени, чем выигрывает. Особенно если клиент в US или Австралии (сервера у нас в Европе). А если соединение по HTTP/2, то разница еще заметнее.

В этом случае CDN на POST должен отвечать 405 Method Not Allowed :-)

если бы Highwinds использовали любую Open Source реализацию HTTP сервера, например Varnish или Nginx

Справедливости ради, nginx очень долго — до версии 1.3.9 — не поддерживал chunked encoding в запросах. Может, у них форк старого nginx.

Один штрих для понимания картины: вы нашли проблему в фазе тестирования сервиса или в продакшене?
Нашли уже после того, как выкатили сайт через CDN (и он пока продолжает так работать, т.к. данная проблема не затрагивает браузеры), но до включения CDN для REST API (оно работает на отдельном домене).
Sign up to leave a comment.

Articles