Здравствуйте, anonymous, Вы писали:
A>Сейчас есть множество расширений протокола, но от заложенного изначально "ограничения" полностью избавиться нельзя, т. е. полноценного дуплекса мы не получим.
Я не очень понимаю, что называется "полноценным дуплексом", но вообще говоря, в HTTP нет только message reordering. Сервер и клиент могут вести передачу достаточно асинхронно, это заложено в протоколе.

Здравствуйте, Shabi, Вы писали:
S>ну...объясни — зачем все эти извращения?
В общем случае — затем, что сервер должен понимать семантику запросов, в частности зависимость результатов запросов от порядка выполнения.
В твоем случае протокол устроен так, что зависимости нет — HTTP об этом не знает. Единственный способ

S>>>...я ж говорю...HTTP ОТСТОЙ
S>>А какой протокол умеет автоматически переупорядочивать запросы?
S>причем тут переупорядочивание ищи по теме full duplex protocol
Поискал. Либо ты используешь какое-то самоизобретенное значение для известного термина, либо я чего-то не понимаю.
Вот смотри: http://www.computerhope.com/jargon/f/fulldupl.htm
В HTTP так и есть: сервер может отдавать данные одновременно с клиентом. Приведи, пожалуйста, свое определение full duplex protocol, можно даже без источника.

S>(я использую самописный протокол. открываеца только один сокет... клиенту ненужно думать о том в какой последовательности кидать вопросы и в какой последовательности придут ответы)
Вот это и есть — переупорядочивание ответов.
S>полагаешь мне обеспечена медалька за прорыв в коммуникациях?
Думаю, что нет. Думаю, что наверняка готовый протокол с поддержкой переупорядочивания сообщений уже есть, и не один.

Здравствуйте, GlebZ, Вы писали:
GZ>Устоялся. Только это называется — ноги от Arpanet'а(RFC 822)
GZ>Ну примерно:
GZ>

GZ><a href="<%# String.Format("~/MyFile.aspx?name={0}&name1={1}&name2={2}", Eval("Name1"),Eval("Name2"),Eval("Name3")) %>">Ошибки</a>
GZ>

GZ>Попробуй напиши это правильно. Так чтобы работало.
А это-то тут причем? 78 символов относится исключительно к заголовкам.
Ограничения на длину URL в стандарте HTTP нету. Большинство реализаций сервера ограничивают URL в 65K — ты устанешь придумывать такую ссылку.
То, что браузеры не умеют работать с URL длиннее 2K, тоже не является виной протокола.

S>>Смотря для чего. Еще раз напомню, что не пользуешься — не платишь. Не нужны русские символы в заголовках (а это редкость, кроме filename в Content-Disposition вроде и некуда особо запихать-то) — не учи RFC 2047.
GZ>Есть еще Content-Description. Но задача по Content-Disposition встречается в каждом втором проекте.
Значит учить RFC 2047 нужно в 50% случаев. Это если ты один делаешь весь проект. А в реальных проектах хэндлеры, которые отдают файлы для Save As, занимают меньше 1% кода, значит в среднем только 1% команды нуждается в деталях этого RFC. Архитектор или Dev Lead, конечно же должен это знать. Но для такой позиции глубокие познания в протоколах и расширениях занимают даже не 50% нужной квалификации. Еще до хрена чего надо знать. Ну а вы как хотели? Лингва латина нон пенис канина. Разработка софта никогда не была простой деятельностью.

GZ>Да понимаешь в чем дело. Не нарушает это Microsoft стандарт. Я то разрабатываю. А администратор ставит.
Ниче не понял. Набор слов какой-то. Есть ясный стандарт на то, что может, а что не может быть доменным именем. За пределами этого поддержка
GZ>ASP.NET приложение каждый запрос пытается аутентифицироваться. Ему и не надо знать что такое http only куки.
Кому не надо?
GZ>Юникс системы он видел только на картинках. Он спец по Microsoft. В результате, потратив свое время на то, чтобы испробоваnm все что можно он звонит не адвокату, не в Microsoft, а мне.. Тратит мое время. А я это — не люблю. Мне платят за разработку.
Ок, значит надо сделать себе отметку, чтобы Login страница сразу выкидывала Exception с текстом "Could not authenticate site located on a host with "_" in name, see RFC 952".
Тогда администратор значительно быстрее поймет, в чем именно он дурак.
Это из области таких вещей, которые неприятно осложняют жизнь, но несмертельны. Туда же идут P3P хидеры — пока что ASP.NET ничего про них не знает, и разработчики раз за разом наступают на грабли типа "сессия теряется в IFRAME". Это gotcha — способ легко унизить на собеседовании кандидата, который думал, что он хорошо разбирается в вопросе.

GZ>>>Ну нет нормальной поддержки в которую можно внедрится безопасно и сэмулировать fs ни в IIS, ни в Apache.
S>>Это не проблема протокола. Не вижу принципиальной проблемы сделать WebDAV Server Framework на, к примеру, .Net.
GZ>Именно этим и приходится периодически заниматься. Опять же, я ленив. Мне нужно блюдечко с голубой каемочкой. А его там нет.
Это не вина протокола. Блюдечка с голубой кайомочкой нет нигде. Я вот всю жизнь сталкивался с тем, что то, чего мне хотелось, в природе отсутствовало. Только потом, лет через пять, это оказывалось самым что ни на есть мейнстримом и попадало в руки индусам. Но к тому моменту передо мной уже стояла следующая задача, и опять везде полный вакуум.

S>>Я вообше пока не уверен, что DAV — сильно хорошая идея. Уж очень он радикально HTTP расширяет. Хотя есть некоторые и удобства — скажем, автоматическая доступность контента в Generic Http клиенте.
GZ>Трабла в том, что прозрачно из DAV файловая система не эмулируется. И соответсвенно, поддержка простых редакторов данной FS — сложная задача. Microsoft вообще работает по нескольким своим стандартам чтобы эмулировать файловую систему через http.

Здравствуйте, vb-develop, Вы писали:
VD>Ну да, сервер удаленный, время отклика порядка 40-50 мс. Хотя я еще не до конца понимаю как на ws клиенте такое реализовать. Все-таки подразумевается синхронный запрос к серверу. А это больше на асинхронные похоже.
Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.

Здравствуйте, misha_irpen, Вы писали:
_>Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
Миша, а какой у вас cache hit ratio?
Покажи пожалуйста на этот сервер — хочу посмотреть, что и куда ездит.

Здравствуйте, Sinclair, Вы писали:

GZ>>

GZ>><a href="<%# String.Format("~/MyFile.aspx?name={0}&name1={1}&name2={2}", Eval("Name1"),Eval("Name2"),Eval("Name3")) %>">Ошибки</a>
GZ>>

GZ>>Попробуй напиши это правильно. Так чтобы работало.
S>А это-то тут причем? 78 символов относится исключительно к заголовкам.
Это задача не на длину, а на перекодирование. Ты серьезно не заметил здесь ошибки?

GZ>>ASP.NET приложение каждый запрос пытается аутентифицироваться. Ему и не надо знать что такое http only куки.
S>Кому не надо?
Админу.

S>Это не вина протокола. Блюдечка с голубой кайомочкой нет нигде. Я вот всю жизнь сталкивался с тем, что то, чего мне хотелось, в природе отсутствовало. Только потом, лет через пять, это оказывалось самым что ни на есть мейнстримом и попадало в руки индусам. Но к тому моменту передо мной уже стояла следующая задача, и опять везде полный вакуум.
Вот и Http — это не блюдечко. Его делали умные люди, но у него серьезные проблемы в связи с наследием Arpanet. У него правда есть одно достоинство которое перевешивает все. Этот стандарт глобален, и поддерживается различными инструментами. И эти инструменты всегда под руками. Посему, пока альтернативы нет, и не будет. Даже когда и появится альтернатива, то ситуация будет напоминать ситуацию с TCPv6. Назрело, но серьезного повсеместного внедрения нет. TCPv4 — поддерживается глобально.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Sinclair, Вы писали:

GZ>>>

GZ>>><a href="<%# String.Format("~/MyFile.aspx?name={0}&name1={1}&name2={2}", Eval("Name1"),Eval("Name2"),Eval("Name3")) %>">Ошибки</a>
GZ>>>

GZ>>>Попробуй напиши это правильно. Так чтобы работало.
S>>А это-то тут причем? 78 символов относится исключительно к заголовкам.
GZ>Это задача не на длину, а на перекодирование. Ты серьезно не заметил здесь ошибки?
Ну, конечно же основная ошибка в том, что URL строится вручную, а не по-взрослому:


GZ>Вот и Http — это не блюдечко. Его делали умные люди, но у него серьезные проблемы в связи с наследием Arpanet. У него правда есть одно достоинство которое перевешивает все. Этот стандарт глобален, и поддерживается различными инструментами. И эти инструменты всегда под руками.
Угу. И очень много вещей, которые автору самопального протокола надо еще продумать, уже продуманы.
GZ>Посему, пока альтернативы нет, и не будет. Даже когда и появится альтернатива, то ситуация будет напоминать ситуацию с TCPv6. Назрело, но серьезного повсеместного внедрения нет. TCPv4 — поддерживается глобально.
Это дополнительное преимущество.

Здравствуйте, Sinclair, Вы писали:

GZ>>Это задача не на длину, а на перекодирование. Ты серьезно не заметил здесь ошибки?
S>Ну, конечно же основная ошибка в том, что URL строится вручную, а не по-взрослому:
[skipped]
По взрослому, это с помощью вещей которые еще не вышли с беты? Вообще же автоматические перекодировщики — это драконы с несколькими головами. С одной стороны в тривиальных случаях хорошо. С другой стороны, для нетривиальных постоянно приходится сверять где и во что перекодируется и в какой вид. Если тебе get запрос надо выполнить в JavaScript, то придется сверяться в каком виде он будет на сервере, в HTML, в JavaScript, и наконец-то будет отослан в виде запроса. При этом амперсенды должны сохраняться в первозданном виде.

Здравствуйте, Sinclair, Вы писали:

_>>Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
S>Миша, а какой у вас cache hit ratio?
А что это?

S>Покажи пожалуйста на этот сервер — хочу посмотреть, что и куда ездит.
ticker.7910.org

Здравствуйте, Sinclair, Вы писали:

S>2. Бинарные RMI/Corba

Уж коль тут строго относятся к пониманию того, что такое протокол, то CORBA это не протокол, протокол называется GIOP

Здравствуйте, Sinclair, Вы писали:

S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня.
S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.

S>Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.

Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.

Здравствуйте, GlebZ, Вы писали:

GZ>Вообще же автоматические перекодировщики — это драконы с несколькими головами. С одной стороны в тривиальных случаях хорошо. С другой стороны, для нетривиальных постоянно приходится сверять где и во что перекодируется и в какой вид. Если тебе get запрос надо выполнить в JavaScript, то придется сверяться в каком виде он будет на сервере, в HTML, в JavaScript, и наконец-то будет отослан в виде запроса. При этом амперсенды должны сохраняться в первозданном виде.

Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки.

Здравствуйте, AndrewVK, Вы писали:

AVK>Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки.
Еще как стремятся. Вопрос по тому, а как же строку накормить датой — пожалуй один из наиболее частых.
Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры. Тебе не надо сериализовать запросы в другую среду, типа Html, или JavaScript. И там нет конфликтующих перекодировок типа HTML.

Здравствуйте, GlebZ, Вы писали:

AVK>>Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки.
GZ>Еще как стремятся.

Если только от большого ума.

GZ> Вопрос по тому, а как же строку накормить датой — пожалуй один из наиболее частых.

То есть лично ты дату отдаешь строкой, как это делаешь в случае URL?

GZ>Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры.

Есть. Тот же TOP/LIMIT/FIRST в большинстве серверов. Или ORDER BY. Только это не означает, что там, где таки можно параметрами, стоит руками собирать строку. Точно так же и с URL. В твоем примере вполне можно использовать какой нибудь LinkLabel и не заниматься ручным перекодированием.

Здравствуйте, Gaperton, Вы писали:
G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
(Побежал в гугл читать про SIP)

Здравствуйте, misha_irpen, Вы писали:
S>>Миша, а какой у вас cache hit ratio?
_>А что это?
Сейчас, Миша, я вам все расскажу.
Для начала — небольшой session transcript:

GET /an1cEUD0cpz1600NjEyOTh2fDAwMDAxMTFkYXxIZWxsbw.gif HTTP/1.1
Accept: */*
Accept-Language: en-us,ru-RU;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: ticker.7910.org
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: lg=en; b=b


HTTP/1.0 200 OK
Server: nginx/0.4.13
Date: Mon, 07 Apr 2008 02:57:52 GMT
Content-Type: image/gif
Content-Length: 15808
Last-Modified: Mon, 07 Apr 2008 02:57:19 GMT
Accept-Ranges: bytes
X-Cache: MISS from gw2.plesk.ru
Connection: keep-alive

GET /an1cEUD0cpz1600NjEyOTh2fDAwMDAxMTFkYXxIZWxsbw.gif HTTP/1.1
Accept: */*
Accept-Language: en-us,ru-RU;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 07 Apr 2008 02:57:19 GMT; length=15808
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Proxy-Connection: Keep-Alive
Host: ticker.7910.org
Pragma: no-cache
Cookie: lg=en; b=b


HTTP/1.0 304 Not Modified
Server: nginx/0.4.13
Date: Mon, 07 Apr 2008 02:58:05 GMT
Last-Modified: Mon, 07 Apr 2008 02:57:19 GMT
X-Cache: MISS from gw2.plesk.ru
Connection: keep-alive

Это я состряпал себе линеечку, посмотрел ее, и нажал F5.
Что интересного можно здесь увидеть?
В ответ на второй запрос мне приходит 304. Это радует, это вы экономите исходящий трафик. Давайте взглянем на статистику объема данных:

                Отправлено Принято
Первый запрос:         369   16057
Второй запрос:         433     189

Что мы видим в статистике? Видим мы 433 байта входящего трафика, которые вас убивают. А знаете, почему? Потому, что вы сэкономили на хидерах cache-control.
У вас же данные исключительно time based. Вы можете предсказывать точное время, когда картинка изменится. А user-agent, увидев правильный хидер expired, не будет посылать вам эти 433 байта и забирать 189.
Попробуйте научить ваш сервер отдавать нормальные хидеры, и ваш входящий трафик уменьшится в разы.

Здравствуйте, Gaperton, Вы писали:

G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
[стошнило]
SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет.

Здравствуйте, Sinclair, Вы писали:

S>Попробуйте научить ваш сервер отдавать нормальные хидеры, и ваш входящий трафик уменьшится в разы.
Спасибо, учтем.

Здравствуйте, misha_irpen, Вы писали:

_>Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
А мне кажется, что если бы формат заголовков был бинарным, то размеры не сократились бы в разы... Так..процентов на 10% наверное. Ведь URL и те же cookie, которые составляют основную по объему часть GET запроса всё равно остались бы текстовыми строками. А можешь привести типичный запрос GET на тот сайт, про который ты написал. Интересно посмотреть сколько всё-таки информации можно сэкономить на бинарном формате.

Здравствуйте, misha_irpen, Вы писали:

_>Спасибо, учтем.
Расскажешь о результатах?
Я бегло посмотрел сервера линеечек в рунете — 100% делают ту же самую ошибку. Т.е. использовать nginx и возвращать 304 догадались все. У вас есть шанс стать первыми, кто сервит линеечки вовсе без обращения к серверу