[apache-rus] Re: [apache-rus] Re: [apache-rus] POST и все,все, все...

[Victor Wagner <vitus@ice.ru>]

On Sun, 16 Jul 2000, Khimenko Victor wrote:

> From: Khimenko Victor <khim@sch57.msk.ru>
> Subject: Re: [apache-rus] Re: [apache-rus] POST и все,все, все...
> X-Mailer: dMail [Demos Mail for DOS v2.07a2]
> 
> In <132359384747.20000714170040@zhurnal.ru> Ilya Obshadko (ilya@zhurnal.ru) wrote:
> IO> Hello Alex,
> 
> IO> пятница, 14 июля 2000 г., you wrote:
> 
> >>> Не понял, отрезается только при POST? Тогда это баг в API charset_bread,
> >>> скорее всего. gdb, httpd -X, и фиксить, фиксить, фиксить...
> 
> AT>> Да, похоже там есть проблемы :)
> 
> IO> Они там однозначно есть. Вспомни историю с multipart-формами.
> 
> А какая история ? Не было там никакой истории. Перекодирование multipart-форм
> в Apache - "bred of wery sif kobyl". Ибо не знает он ни про какие-такие
> multipart-формы. Что пришло - то и скормили в скрипт или еще куда.

Если бы! А то имеется такая ситуация - есть multipart форма, на которую
не стоит charsetRecodeMultipartForm Off. С чего бы ему там стоять, если
через эту форму гоняются не гифы, а HTML-и, которые перекодировать надо?

И вот систематически (но не всегда) получается что русский апач отдает
обработчику меньше байт, чем написано в Content-Length, на что CGI.pm
естественно, говорит die.

В результате все, кого это колышет, используют для перекодировки таких
форм либо Apache::Charset, либо  вообще что-нибудь свое (я использую
вообще что-нибудь свое потому что у меня через ту же форму Rtf-ы ходят,
а в них часто Unicode бывает, с которым Apache::Charset не справляется)
 
> IO> Которые я сейчас перекодирую из скрипта при помощи Apache::Charset. ;)
> 
> А как их еще перекодировать ? Тебе-то всяко MIME разбирать приходится - деваться

В лоб и напрямую - разнести данные которые перекодированию подлежат,
и которые оному не подлежат по разным формам. Так было до недавнего
времени у меня (теперь отказался, поскольку все равно ни хрена не
перекодируется), так сделано у Ильи.  

> А вот в charset_bread'е проблемы там есть. charset_bread неправильно
> работает в одном-единственном, казалось бы, маловероятном случае: когда
> его попросили считать сначала, скажем, 4096 байт так, что "на стык"
> попала %XX последовательность (после чего charset_bread вернет
> 4095 или 4094 байта :-), а затем попросили прочитать один или

О! Вот она причина.
> два байта. В этом случае charset_bread вернет 0 - признак конца !
> Казалось бы - КАК такое может произойти ? Ну кому может придти в
> голову читать по одному-два байтам ??? Ответ: системе буферизации apache.
> Когда оно видит, что ему вернули не полный буффер, а немного "недодали",
> то он просит дочитать еще "чуть-чуть" чтобы дополнить буффер.
> Далее - см. выше.

 
> Паtch при'attach'ен. С multipart формами пусть разбирается кто-нибудь
> другой: ясно, что это можно сделать "заглядывая вперед" подальше, но вот
> сложность кода и его размеры явно превзойдут разумные пределы... Про
> скорость я уж и вообще молчу. Вот с unicode можно было бы попробовать
> разобраться, но это требует отдельных таблиц: unicode -> current_charset
> и т.п. Хороший проектик для кого-нибудь, кому нечем на выходных заняться :-)
 
> P.S. Вообще безумие все это: столько слез было, а вот вооружиться gdb и
> потратить час никому в голову не пришло :-( Grrr.
 
Безумие-то оно конечно безумие. Но вот для того чтобы вооружиться GDB
и  Internet-Explorer-ом на одном десктопе надо что-то нетривиальное
предпринять. Вообще, конечно, давно пора иметь на девелопмент-сервере
прокси, которая клиентские запросы полностью в лог пишет и потом из этого
лога тривиальным скриптом на perl  их на сервер дублировать.
 
 

-- 
Victor Wagner			vitus@ice.ru
Programmer			Office:7-(095)-785-09-72
Communiware.Net 		Home: 7-(095)-135-46-61
http://www.communiware.net      http://www.ice.ru/~vitus

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