You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Gareth Coltman <ga...@majorband.co.uk> on 2001/09/17 18:16:12 UTC
PLEASE HELP ME
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?
Gareth
> -----Original Message-----
> From: Gareth Coltman [mailto:gareth_coltman@majorband.co.uk]
> Sent: Monday, September 17, 2001 14:19
> To: turbine-dev@jakarta.apache.org
> 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: PLEASE HELP ME (possible patch)
Posted by Jason van Zyl <jv...@apache.org>.
On 9/18/01 8:04 AM, "Gareth Coltman" <ga...@majorband.co.uk> wrote:
> Ok,
>
> The problem lies not with the parameter parser but with the
> TurbineUploadService itself.
>
> (See public void parseRequest(HttpServletRequest req, ParameterParser params,
> String path) in the TurbineUploadService class)
>
> When processing a multipart/form-data request all parts of the forms are
> treated like FileItems to effectively handle large amounts
> of data and different content types. All this data is pushed into a FileItem
> through an output stream (as bytes).
>
> When the non-file data is added to the parameter parser, it is accessed using
> the FileItem.get() method, which does not take account
> of encoding. If have updated this to:
>
>
> String encoding =
> TurbineResources.getString("services.UploadService.encoding");
Use the services configuration, I'm trying to get people to stop using
TurbineResources in other services. Is this in the TurbineUploadService
code?
If so use
configuration.getString(encoding)
instead.
>
> if(encoding != null)
> {
> params.append(getFieldName(headers),
> item.getString(encoding));
> }
> else
> {
> params.append(getFieldName(headers),
> new String(item.get()));
> }
> Where services.UploadService.encoding is a new property in
> TurbineResources.properties. If no encoding is specified then the bytes
> are just read as 7-bit ASCII (this might be the default encoding on the JVM's
> system?) This will obviously throw an exception in the
> encoding string is invalid.
>
> I'm not sure if this is best place to fix this, but it works fine now.
I think it will be hard to unify the handling of the encoding in a unified
way without using a "global" property. I'll take a peek to see what can be
done as it's definitely a must for 3.0.
> Is this worth a patch?
I think so, send it on down the pipe and I'll try it with the little
download service test in the tdk.
> Gareth
>
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jvanzyl@apache.org]
>> Sent: Monday, September 17, 2001 18:13
>> To: turbine-dev@jakarta.apache.org
>> Subject: Re: PLEASE HELP ME
>>
>>
>> On 9/17/01 12:58 PM, "Gareth Coltman" <ga...@majorband.co.uk>
>> 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:jvanzyl@apache.org]
>>>> Sent: Monday, September 17, 2001 17:26
>>>> To: turbine-dev@jakarta.apache.org
>>>> Subject: Re: PLEASE HELP ME
>>>>
>>>>
>>>> On 9/17/01 12:16 PM, "Gareth Coltman"
>> <ga...@majorband.co.uk>
>>>> 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:gareth_coltman@majorband.co.uk]
>>>>>> Sent: Monday, September 17, 2001 14:19
>>>>>> To: turbine-dev@jakarta.apache.org
>>>>>> 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:
>> turbine-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail:
>>>> turbine-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail:
>> turbine-dev-help@jakarta.apache.org
>>>>
>>>> --
>>>>
>>>> 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: turbine-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>> turbine-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>> --
>>
>> 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: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: PLEASE HELP ME (possible patch)
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Ok,
The problem lies not with the parameter parser but with the TurbineUploadService itself.
(See public void parseRequest(HttpServletRequest req, ParameterParser params, String path) in the TurbineUploadService class)
When processing a multipart/form-data request all parts of the forms are treated like FileItems to effectively handle large amounts
of data and different content types. All this data is pushed into a FileItem through an output stream (as bytes).
When the non-file data is added to the parameter parser, it is accessed using the FileItem.get() method, which does not take account
of encoding. If have updated this to:
String encoding = TurbineResources.getString("services.UploadService.encoding");
if(encoding != null)
{
params.append(getFieldName(headers),
item.getString(encoding));
}
else
{
params.append(getFieldName(headers),
new String(item.get()));
}
Where services.UploadService.encoding is a new property in TurbineResources.properties. If no encoding is specified then the bytes
are just read as 7-bit ASCII (this might be the default encoding on the JVM's system?) This will obviously throw an exception in the
encoding string is invalid.
I'm not sure if this is best place to fix this, but it works fine now.
Is this worth a patch?
Gareth
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@apache.org]
> Sent: Monday, September 17, 2001 18:13
> To: turbine-dev@jakarta.apache.org
> Subject: Re: PLEASE HELP ME
>
>
> On 9/17/01 12:58 PM, "Gareth Coltman" <ga...@majorband.co.uk>
> 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:jvanzyl@apache.org]
> >> Sent: Monday, September 17, 2001 17:26
> >> To: turbine-dev@jakarta.apache.org
> >> Subject: Re: PLEASE HELP ME
> >>
> >>
> >> On 9/17/01 12:16 PM, "Gareth Coltman"
> <ga...@majorband.co.uk>
> >> 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:gareth_coltman@majorband.co.uk]
> >>>> Sent: Monday, September 17, 2001 14:19
> >>>> To: turbine-dev@jakarta.apache.org
> >>>> 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:
> turbine-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail:
> >> turbine-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> turbine-dev-help@jakarta.apache.org
> >>
> >> --
> >>
> >> 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: turbine-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> turbine-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
> --
>
> 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: PLEASE HELP ME
Posted by Jason van Zyl <jv...@apache.org>.
On 9/17/01 12:58 PM, "Gareth Coltman" <ga...@majorband.co.uk>
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:jvanzyl@apache.org]
>> Sent: Monday, September 17, 2001 17:26
>> To: turbine-dev@jakarta.apache.org
>> Subject: Re: PLEASE HELP ME
>>
>>
>> On 9/17/01 12:16 PM, "Gareth Coltman" <ga...@majorband.co.uk>
>> 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:gareth_coltman@majorband.co.uk]
>>>> Sent: Monday, September 17, 2001 14:19
>>>> To: turbine-dev@jakarta.apache.org
>>>> 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: turbine-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>> turbine-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>> --
>>
>> 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: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: PLEASE HELP ME
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Thanks
Well as the default encoding for html is ISO-8859-1, this would make more sense. What do you think?
Thanks.
Gareth
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@apache.org]
> Sent: Monday, September 17, 2001 17:26
> To: turbine-dev@jakarta.apache.org
> Subject: Re: PLEASE HELP ME
>
>
> On 9/17/01 12:16 PM, "Gareth Coltman" <ga...@majorband.co.uk>
> 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:gareth_coltman@majorband.co.uk]
> >> Sent: Monday, September 17, 2001 14:19
> >> To: turbine-dev@jakarta.apache.org
> >> 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: turbine-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> turbine-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
> --
>
> 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: PLEASE HELP ME
Posted by Jason van Zyl <jv...@apache.org>.
On 9/17/01 12:25 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> On 9/17/01 12:16 PM, "Gareth Coltman" <ga...@majorband.co.uk>
> wrote:
>
> 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.
In 2.x there is no decent way for a character encoding to flow through the
system so that each tool use it. In 3.x we can pick off the locale and than
use the MimeTypeService to map the locale to the most appropriate character
encoding than make sure that this character encoding is used in all the
appropriate places.
I'm taking a quick peek at the RunData service and I believe that we can
control the parameters used in the construction of an object. The
BaseValueParser constructor class takes a parameter for the character
encoding so maybe we could quickly make the RunDataService construct a
ParameterParser with an encoding. This won't flow through the rest of the
system but will work for anything that the RunDataService constructs. I'll
give it a try and let you know.
If you want to just change the hardcoded "US-ASCII" value in BaseValueParser
and try your app I'd be interested in the results. Would be a work around
for people having problems like yourself.
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: PLEASE HELP ME
Posted by Jason van Zyl <jv...@apache.org>.
On 9/17/01 12:16 PM, "Gareth Coltman" <ga...@majorband.co.uk>
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:gareth_coltman@majorband.co.uk]
>> Sent: Monday, September 17, 2001 14:19
>> To: turbine-dev@jakarta.apache.org
>> 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: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org