On 9/17/01 12:58 PM, "Gareth Coltman" <[EMAIL PROTECTED]>
wrote:
> Thanks
>
> Well as the default encoding for html is ISO-8859-1, this would make more
> sense. What do you think?
As a stop gap measure I don't think it will hurt anything, you want to give
it a try?
> Thanks.
>
> Gareth
>
>> -----Original Message-----
>> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, September 17, 2001 17:26
>> To: [EMAIL PROTECTED]
>> Subject: Re: PLEASE HELP ME
>>
>>
>> On 9/17/01 12:16 PM, "Gareth Coltman" <[EMAIL PROTECTED]>
>> wrote:
>>
>>> I have posted this before, so my apologies for repeating
>> myself. I just need
>>> someone to point me in the right direction.
>>>
>>> When I put enctype="multipart/form-data" into my form, the
>> upload service
>>> automatically saves the files as I expected. The problem
>>> is that it uses a strange character encoding (actually its
>> probably 8-bit
>>> ascii) when uploading the other parts of the form. This
>>> means that if the user enters a pound sterling sign into a
>> text element in the
>>> form, it becomes a ? by the time I request the
>>> formdata in Turbine.
>>>
>>> If I don't use the enctype="multipart/form-data" attribute, it works
>>> perfectly, but obviously doesn't upload the files.
>>>
>>> Can anybody tell me where to start?
>>
>> The encoding specified in the
>> org.apache.turbine.util.parser.BaseValueParser
>> is "US-ASCII". We could probably pick better default encoding
>> which might be
>> a little more forgiving.
>>
>>> Gareth
>>>
>>>> -----Original Message-----
>>>> From: Gareth Coltman [mailto:[EMAIL PROTECTED]]
>>>> Sent: Monday, September 17, 2001 14:19
>>>> To: [EMAIL PROTECTED]
>>>> Subject: RE: Removing redirect behaviour
>>>>
>>>>
>>>> Thanks for responding. I am still unsure about a few things.
>>>>
>>>>>
>>>>> a) that session tracking is functional on the particular
>>>>> combination of
>>>>> browser/container/etc without entering an infinite redirect loop,
>>>>
>>>> The only reason it would enter an infinite loop though is
>>>> because Turbine sends it into one!? i.e. If session tracking is not
>>>> working then turbine sends it into a loop, but catches this
>>>> and throws an infinite redirect error. Do I really need
>> this if I am
>>>> working with a standard app server like Tomcat?
>>>>
>>>>> b) that no redirect specifies the same URL as the request
>>>>
>>>> Actually turbine doesn't catch this if it is done by the
>>>> application, only if it happens on the initial (new
>> session) request.
>>>>
>>>> Has anybody else removed this code and then had problems?
>>>> What browsers give problems? I would love someone to convince
>>>> me that it
>>>> is necessary, but I just can't see how.
>>>>
>>>> Gareth
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>> --
>>
>> jvz.
>>
>> Jason van Zyl
>>
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
