Article delegate-en/1203 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]

Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Multipart Form
15 Jun 2001 21:01:30 GMT pwecabdyi-dyd2yvd265xr.ml@ml.delegate.org



I actually found the problem... It ended up being a redirect sent from the
HTTP server that was not being re-hashed by DeleGate properly.  So I
implemented a FFROMSV CFI filter that was:
Content-Type: text/html
Header-Filter: sed 's/http:\/\//http:\/\//'

As much sense as this does not make (the before and after are the SAME).
It works.. and was the only thing that fixed it.

Any thoughts?

Chad





feedback@delegate.org (Yutaka Sato) on 06/15/0000 00:00:0X PM

Please respond to feedback@delegate.org

To:   feedback@delegate.org
cc:   Chad Milam/WWIT/J Walter Thompson@JWT
Subject:  Re: [DeleGate-En] Multipart Form


On 06/16/01(00:40) you pwecabdyi-dyd2yvd265xr.ml@ml.delegate.org wrote
in <_A1201@delegate-en.ML_>
 |I am running a perl script as a FTOCL CFI filter.  The problem is, since
I
 |have implemented it, my multipart/form-data ENCTYPE forms no longer work.

Since FTOCL specifies a filter applied to response message to client,
it is difficut to think it will affect uploading data in request
message (of multipart/form-data type) from client.

 |What would be a good work arond for this?  Everything else seems to work
 |perfect.  Just the forms that allow HTTP uploads do not.  Thoughts?

Does not the problem occur without the FTOCL parameter?
If so, what is different between log data with/without FTOCL?

Cheers,
Yutaka
--
  @ @ Yutaka Sato <y.sato@delegate.org> http://www.delegate.org/y.sato/
 ( - ) National Institute of Advanced Industrial Science and Technology
(AIST)
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan








  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V