ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] Конец строки в POST



>>>>> On Thu, 11 Mar 1999 18:55:33 +0300 (MSK), "Khimenko Victor" 
><khim@sch57.msk.ru> said:

 AC> во-вторых, что более серьезно, меня совершенно не устраивает его
 AC> функциональность, и потому я им не пользуюсь.

 KV> Гм. А что в нем так уж криво ?

Генерация html.  В <select>, когда надо отсортировать по labels, что
требуется на порядок чаще, чем наоборот, правильный порядок сортировки
можно получить только из запроса к базе с order by и почленным
заполнением массива values.  А попробуй правильно отсортировать только
средствами перла!  А если обрабатываются ошибки и хочется вывести все,
что удалось до ошибки собрать, то все равно лучше собирать руками --
тогда где-то перед началом eval достаточно объявить один скаляр вместо
массива и хеша.  Да и памяти на сбор select'а сразу в строку требуется
где-то втрое меньше.  Тег <tr> мы почему-то умеем только целиком, по
частям (отдельно <tr>, отдельно </tr>) нам почему-то недоступно.  Хотя
покажите мне ситуацию, когда удобно выдать сразу всю строку таблицы.
Вот и получается: когда пишешь $q->tag(), когда просто "<tag>".  А потом
черт ногу сломит в этом скрипте...

 AC> Поднимать его ради разбора multipart/form-data, если он ее
 AC> умеет -- нафиг, нафиг.

 KV> Мы лучше свой велосипед построим ! "Национальная гордость великороссов" ?

Как тебе сказать...  HTML мы генерим хреново и неудобно для
программиста.  Функциональность GET и всяких редиректов модуль Apache
нам перекрывает с головой.  Немножко уступает в обычном POST (не
разбирает сразу на параметры) и не реализован multipart/form-data.  Вот
тебе и велосипед.  Apache мы все равно use, авторизации и информации о
конфигурации ради, и покажите мне теперь смысл забивать память модулем
CGI.

 VBW> Вообще, написать код, который понимает все три вида концов строк -
 VBW> несложно,

 AC> Но длинно.

 KV> RFC1867 ссылается на MIME, где все строки должны кончаться на CRLF. 
Соблюдают
 KV> ли все browser'ы это требование -- бог весть... То, что MS IE стандарты не
 KV> соблюдает (и посылает-таки \n -- сам на это нарывался :-) -- это уже как бы
 KV> добрая традиция, а вот есть ли кто-нибудь еще -- не знаю...

Ну что ж, this site does not support M$ IE.  And never will.  Ссылка на
стандарт у меня теперь есть, остальное проблемы юзеров.

 KV> Он и не обязан :-) Зато ты обязан склеивать строки, разбираться с commenets
 KV> и quoted-strings (RFC2045, Appendix A; RFC822, 3.4.8, 3.4.3 и 3.4.5)...

А кто при multipart/form-data режет заголовки и кодирует строки?

 KV> А есть еще ошибки Netscape'а (он неправ, забывая обрабатывать кавычки в
 KV> именах файлов, но жаловаться-то будут тебе :-)

А что, CGI это обрабатывает?  С нетшкафом довольно просто -- filename=
имеет тенденцию заканчивать строку, так что соответствующий регексп
выглядит

\bfilename="(.+)"\s*$

 KV>  и MS IE (MS IE для Mac'а
 KV> забывает добавлять "--" к boundary :-)

В начало или в конец?  Впрочем, маков у нас внутри нет.

 KV> В общем изобретение велосипеда -- вещь похвальная, но хлопотная...

Может, ты и уговорил завести на это CGI...  Но вообще, мрачный модуль.
Я лучше попробую выкусить из него нужную функцию.

=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.