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 13:49:24 UTC
Removing redirect behaviour
Hi,
Can anybody give me a good reason why I should NOT remove the first access redirect behaviour from my version of turbine? This is
where a new request is immediately redirected back to the same page, adding redirected=true into the parameters. The only useful bit
of functionality encapsulated in this section of code is setting the session timeout. I am planning to edit Turbine.java to set
Session Timeout if data.getSession.isNew() with no other conditions. I just can't understand what it is for.... Sorry.
I have a vague recollection that this weird behaviour was to fix a mozzila bug... Or is it to stop a DOS attack.... Can anybody shed
any light on this?
Gareth
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Removing redirect behaviour
Posted by Sean Legassick <se...@informage.net>.
In message <00...@rightmove1>, Gareth Coltman
<ga...@majorband.co.uk> writes
>> It looks like that is the problem. Hmmm... that's even more
>> broken than
>> the redirect mechanism is designed to catch. I think I can
>> see a way to
>> protect against this as well.
>
>Please tell me more!
Sorry - I was just musing on the subject, not got the fix fully clear in
my head yet but I'll give it a hack over the weekend. To do with looking
at the full request URI rather than just parsed request params to spot
the infinite redirect.
--
Sean Legassick
sean@informage.net
Soy un hombre: nada humano me es extrano
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Removing redirect behaviour
Posted by Sean Legassick <se...@informage.net>.
In message <00...@rightmove1>, Gareth Coltman
<ga...@majorband.co.uk> writes
>> It looks like that is the problem. Hmmm... that's even more
>> broken than
>> the redirect mechanism is designed to catch. I think I can
>> see a way to
>> protect against this as well.
>
>Please tell me more!
Gareth,
I've committed a simple amendment - I'd be grateful if you could try it
with your broken Mozilla and see if it catches the infinite redirect.
Thanks,
--
Sean Legassick
sean@informage.net
Jeg er mann: Ingenting menneskelig er fremmed for meg
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Removing redirect behaviour
Posted by Gareth Coltman <ga...@majorband.co.uk>.
> It looks like that is the problem. Hmmm... that's even more
> broken than
> the redirect mechanism is designed to catch. I think I can
> see a way to
> protect against this as well.
Please tell me more!
Gareth
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Removing redirect behaviour
Posted by Sean Legassick <se...@informage.net>.
In message <00...@rightmove1>, Gareth Coltman
<ga...@majorband.co.uk> writes
>And so on until a "request too long" error occurs.
>
>Somehow it is just continually redirecting. Is tomcat not recognizing
>the jsession because it is encoding = and ? as %3????
It looks like that is the problem. Hmmm... that's even more broken than
the redirect mechanism is designed to catch. I think I can see a way to
protect against this as well.
--
Sean Legassick
sean@informage.net
Als Mensch kann mir nichts menschliches Fremd sein
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Removing redirect behaviour
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Hmm,
Ok, I have discoved another interesting problem that is occuring when mozilla 3 users (through Liberate DTV access our site).
The log looks like this:
194.6.2.151 - - [18/Sep/2001:10:18:16 +0100] "GET / HTTP/1.0" 302 214 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:18 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91 HTTP/1.0" 302 231 "-" "Mozilla/
3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:18 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91%3Bjsessionid%3Dswzwckcx92 HTTP/
1.0" 302 257 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:19 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91%3Bjsessionid%3Dswzwckcx92%3Bjse
ssionid%3Dcyc5b1cx93%3Bjsessionid%3D1psr38cx94 HTTP/1.0" 302 309 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:19 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91%3Bjsessionid%3Dswzwckcx92%3Bjse
ssionid%3Dcyc5b1cx93%3Bjsessionid%3D1psr38cx94%3Bjsessionid%3Dadjal1cx95 HTTP/1.0" 302 335 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:21 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91%3Bjsessionid%3Dswzwckcx92%3Bjse
ssionid%3Dcyc5b1cx93%3Bjsessionid%3D1psr38cx94%3Bjsessionid%3Dadjal1cx95%3Bjsessionid%3Dtjkb23cx96%3Bjsessionid%3D6hovtrcxa1 HTTP/1.
0" 302 387 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:22 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91%3Bjsessionid%3Dswzwckcx92%3Bjse
ssionid%3Dcyc5b1cx93%3Bjsessionid%3D1psr38cx94%3Bjsessionid%3Dadjal1cx95%3Bjsessionid%3Dtjkb23cx96%3Bjsessionid%3D6hovtrcxa1%3Bjsess
ionid%3Dgejggrcxa2%3Bjsessionid%3Dv1jqnjcxb1 HTTP/1.0" 302 439 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
194.6.2.151 - - [18/Sep/2001:10:18:25 +0100] "GET /rm/s/rm/redirected/true%3Bjsessionid%3Do6q4cpcx91%3Bjsessionid%3Dswzwckcx92%3Bjse
ssionid%3Dcyc5b1cx93%3Bjsessionid%3D1psr38cx94%3Bjsessionid%3Dadjal1cx95%3Bjsessionid%3Dtjkb23cx96%3Bjsessionid%3D6hovtrcxa1%3Bjsess
ionid%3Dgejggrcxa2%3Bjsessionid%3Dv1jqnjcxb1%3Bjsessionid%3D86453lcxb2%3Bjsessionid%3Drb60y2cxb3%3Bjsessionid%3Dg88hahcxc1 HTTP/1.0"
302 517 "-" "Mozilla/3.0 (Liberate DTV 1.1)"
And so on until a "request too long" error occurs.
Somehow it is just continually redirecting. Is tomcat not recognizing the jsession because it is encoding = and ? as %3????
Any clues?
Gareth
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Removing redirect behaviour
Posted by Sean Legassick <se...@informage.net>.
In message <00...@rightmove1>, Gareth Coltman
<ga...@majorband.co.uk> writes
>> 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.
Correct.
>Do I really need this if I am
>working with a standard app server like Tomcat?
Its common practice when working with the servlet API to do a redirect
to establish that session-tracking is functioning correctly. Do you
really need it? That depends on how upset you would be if some
browser/proxy/container combination broke session tracking and sent the
user session into an infinite redirect loop.
>> 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.
Sorry yes, I was only referring to the framework-generated redirects in
the initial session setup phase.
>Has anybody else removed this code and then had problems?
Actually I had problems then added the code to fix them.
>What browsers give problems?
Mozilla certainly did cause problems back when this code was added.
>I would love someone to convince me that it
>is necessary, but I just can't see how.
It is not strictly "necessary". It is useful functionality (what a
framework is there for) as it protects your application against a broken
element in the browser->container chain. Note that some of the software
in that chain is out of your control (assuming an Internet based
deployment).
--
Sean Legassick
sean@informage.net
Jeg er mann: Ingenting menneskelig er fremmed for meg
---------------------------------------------------------------------
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
PLEASE HELP ME
Posted by Gareth Coltman <ga...@majorband.co.uk>.
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: Removing redirect behaviour
Posted by Gareth Coltman <ga...@majorband.co.uk>.
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
Re: Removing redirect behaviour
Posted by Sean Legassick <se...@informage.net>.
In message <00...@rightmove1>, Gareth Coltman
<ga...@majorband.co.uk> writes
>Can anybody give me a good reason why I should NOT remove the first
>access redirect behaviour from my version of turbine? This is
>where a new request is immediately redirected back to the same page,
>adding redirected=true into the parameters. The only useful bit
>of functionality encapsulated in this section of code is setting the
>session timeout. I am planning to edit Turbine.java to set
>Session Timeout if data.getSession.isNew() with no other conditions. I
>just can't understand what it is for.... Sorry.
>
>I have a vague recollection that this weird behaviour was to fix a
>mozzila bug... Or is it to stop a DOS attack.... Can anybody shed
>any light on this?
The redirects are in place to ensure:
a) that session tracking is functional on the particular combination of
browser/container/etc without entering an infinite redirect loop,
b) that no redirect specifies the same URL as the request URL, as some
browsers (yes, notably mozilla) will get upset about this.
--
Sean Legassick
sean@informage.net
ignorance is not bliss
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Getting the ID of the last inserted JobEntry?
Posted by Hristo Kosev <hk...@yahoo.com>.
hi,
can someone tell me if there's a way to get the ID of
the last inserted JobEntry. I think the JobEntry
mapbuilder is set to use IDBroker instead of
autoincrement so I can't get the ID using the standard
SQL functions/variables.
Hristo Kosev
__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting the ID of the last inserted JobEntry?
Posted by Heiko Braun <he...@fork.de>.
After you called foo.save() on your om object,
the id is available via foo.getFooId();
/heiko
On Tue, 18 Sep 2001, Hristo Kosev wrote:
> hi,
> can someone tell me if there's a way to get the ID of
> the last inserted JobEntry. I think the JobEntry
> mapbuilder is set to use IDBroker instead of
> autoincrement so I can't get the ID using the standard
> SQL functions/variables.
>
> Hristo Kosev
>
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
> http://dailynews.yahoo.com/fc/US/Emergency_Information/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Getting the ID of the last inserted JobEntry?
Posted by Hristo Kosev <hk...@yahoo.com>.
hi,
can someone tell me if there's a way to get the ID of
the last inserted JobEntry. I think the JobEntry
mapbuilder is set to use IDBroker instead of
autoincrement so I can't get the ID using the standard
SQL functions/variables.
Hristo Kosev
__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Removing redirect behaviour
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Yes, but this doesn't add the timeout. I guess I could add this in the session validator?
Would (pseudo)
if session.isNew
setExpiryTime
work in the session validator?
Gareth
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Monday, September 17, 2001 18:52
> To: turbine-dev
> Subject: Re: Removing redirect behaviour
>
>
> on 9/17/01 4:49 AM, "Gareth Coltman"
> <ga...@majorband.co.uk> wrote:
>
> > Hi,
> >
> > Can anybody give me a good reason why I should NOT remove
> the first access
> > redirect behaviour from my version of turbine? This is
> > where a new request is immediately redirected back to the
> same page, adding
> > redirected=true into the parameters. The only useful bit
> > of functionality encapsulated in this section of code is
> setting the session
> > timeout. I am planning to edit Turbine.java to set
> > Session Timeout if data.getSession.isNew() with no other
> conditions. I just
> > can't understand what it is for.... Sorry.
> >
> > I have a vague recollection that this weird behaviour was
> to fix a mozzila
> > bug... Or is it to stop a DOS attack.... Can anybody shed
> > any light on this?
> >
> > Gareth
>
> You can remove it by creating a SessionValidator and
> returning false from
> the requiresNewSession() method.
>
> -jon
>
>
> ---------------------------------------------------------------------
> 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: Removing redirect behaviour
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/17/01 4:49 AM, "Gareth Coltman" <ga...@majorband.co.uk> wrote:
> Hi,
>
> Can anybody give me a good reason why I should NOT remove the first access
> redirect behaviour from my version of turbine? This is
> where a new request is immediately redirected back to the same page, adding
> redirected=true into the parameters. The only useful bit
> of functionality encapsulated in this section of code is setting the session
> timeout. I am planning to edit Turbine.java to set
> Session Timeout if data.getSession.isNew() with no other conditions. I just
> can't understand what it is for.... Sorry.
>
> I have a vague recollection that this weird behaviour was to fix a mozzila
> bug... Or is it to stop a DOS attack.... Can anybody shed
> any light on this?
>
> Gareth
You can remove it by creating a SessionValidator and returning false from
the requiresNewSession() method.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org