информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медСтрашный баг в WindowsГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / web building
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Кому интересно, вот что получилось (внутри). 01.03.10 12:25  Число просмотров: 2969
Автор: 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>
Как задаётся имя скачиваемого контента в браузере? 22.02.10 13:58  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 22.02.10 14:05  Количество правок: 2
<"чистая" ссылка>
Предположим, есть страница http://url.com/getFile.cgi?fileid=12345.
Сервер указывает в заголовках браузеру MIME-тип application/octet-stream.
Это заставляет браузер сохранить файл с именем getFile.cgi.
Можно ли указать сервером браузеру другое имя для сохранения файла?
Ну, конечно пользователь может подставить другое имя в диалоге сохранения (например), но там уже должно быть вбито по умолчанию нужное имя (не getFile.cgi)

Заранее всем спасибо за ответы.
Кому интересно, вот что получилось (внутри). 01.03.10 12:25  
Автор: 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 позволяет указать смещение и длину).

Такие вот пироги.
заголовок Content-Disposition 22.02.10 14:53  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
В частности тут аттачи отдаются так:

print "Content-Type: application/octet-stream\n";
print "Content-Disposition: attachment; filename=$fname\n";
[...]
Всё ясно, спасибо! 22.02.10 15:13  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
1




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


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