информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяГде водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / web building
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Кому интересно, вот что получилось (внутри). 01.03.10 12:25  Число просмотров: 2759
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 01.03.10 13:31  Количество правок: 5
<"чистая" ссылка>
Сколько, оказывается, доп. геморроя!

1) Проблема с русским языком в именах файлов -- хотя вроде под вин платформой все поняли Win1251 кодировку. Не знаю, что будет под другими системами. Говорят, URLEncode прокатывает, но опять же, кодируем Win1251 ASCII. Браузеры понимают urlEncoded, wget понимает только Win1251, короче, печалит, что HTTP стандарты заставляют в заголовках использовать 7-битный ASCII в XXI веке. Я уже сталкивался с этим неприятным явлением, например, в Basic HTTP авторизации при попытке указать realm на русском языке.

2) Жаль, что нет HTTP заголовка, который бы заставлял браузер брать файл по другому адресу. Редирект не подходит, потому что задача -- указать имя, а при редиректе все наши установленные заголовки "слетят". Эх, вот если бы ещё был параметр для content-disposition навроде "content-url" -)

3) Пляски на стороне сервера -- крутился классический ASP на IISv6. Выключаем кеш вывода (Response.Buffer = FALSE). Есть метод Response.WriteBinary. Но классический ASP не имеет средств для работы с файлами! Нужно использовать внешние COM компоненты -- например, вендовый Scripting.FSO, но он крайне уродлив (нет методов бинарного чтения). Cамый подходящий метод прочитать бинарный контент оказался использовать вендовый ADO Stream object. Хорошо, используем ADO -- его мы любим и знаем -- шикарная тема для работы с БД, посмотрим, как тут заработает...
У него к тому же есть свойство Size -- ура! можем выставлять заголовок Content-Length (кагбэ хороший тон для HTTP сервера).
При попытке выкачать файл объёмом 300 метров, HTTP процесс сервера "вспух" на это кол-во мегабайт (и сдувается только после окончания или прерывания закачки на клиентской стороне ;)
Выяснилось, что ADO Stream грузит контент полностью в память после вызова метода LoadFromFile. Вот такая вот реализация Stream, тьфу, @#$ть, слов нет, низачот в карму разрабам ADO.
Пришлось включать ASP.NET на сервере. Заодно появилась маза поизучать .NET. Ну как бы есть плюшки -- JIT компиляция (при первом доступе к .aspx странице), роскошная иерархия классов. Я это всё люблю -) Причём, можно конечно файл открыть ручками, самому его читать и скидывать в Response, но оказалось, есть Response.TransmitFile, остро заточенный под это дело.

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

5) Оказывается, некие UA (например wget), при указании опции --content-disposition (по умолчанию эта фишка там отключена (ПОЧЕМУ!!!)), сперва шлёт HEAD (ЗАЧЕМ!!!), а потом только GET. Веб-сервер отдаст запрос скрипту и отдаст UA только заголовки, что скрипт нагенерил, остальное отфильтрует. Поэтому включил реакцию на запрос HEAD в скрипт: отдавать тело файла только при нормальных запросах, не делать лишней работы.

6) Всё равно осталось чувство некоей неудовлетворённости. Обрабатывающий поток может висеть часами на синхронном TranmitFile (если файл большой, канал пользователя медленный). Хостеры такое не любят -- могут поток рубить принудительно. Как выход, сообщить UA, что возможна докачка, имплементировал докачку (кидаю в заголовки Accept-Ranges: bytes и анализирую, если попросили докачку, TransmitFile позволяет указать смещение и длину).

Такие вот пироги.
<web building> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach