You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Geoff Callender <ge...@gmail.com> on 2008/08/27 00:12:14 UTC
Invalid requests - best practice?
I'm looking for thoughts on the best way to handle this situation that
almost every page has to deal with.
Let's say the user chose http://myhost/myapp/products/123, so the
Products page tries to get product 123 in onActivate. What if the
product doesn't exist, or the user is not authorised to view the
product? I see 3 options:
1. Handle it on the same page - either display the product or display
the error, on the same page.
2. Return a new page, possibly setting it up with a message.
3. Throw an exception and interpret it in your app's exception page.
The exception page could give certain exceptions special treatment eg.
DoesNotExistException and NotAuthorisedException might get different
treatment to unexpected exceptions.
Approach 1 has the big advantage that it keeps the same URL - the user
can see what they requested.
Approach 2 gives you complete control over the page they see but the
user can no longer see the URL they requested.
Approach 3 is really simple to implement.
Are there other considerations? Is one of these more RESTful?
Cheers,
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Invalid requests - best practice?
Posted by Geoff Callender <ge...@gmail.com>.
Kalle, thanks for the suggestion. I'll add it in to the mix.
Geoff
On 29/08/2008, at 6:07 AM, Kalle Korhonen wrote:
> JMHO, but I think it depends on the case. In your product example,
> I'd let
> the page itself handle the error since it's relatively clear the
> user tried
> to access a non-existent (possibly removed or non-authorized)
> product. For a
> completely random, non-existent url, I'd try to handle it as soon as
> possible with a generic 404 page. Throwing exceptions is expensive,
> especially on open web there will be crawlers and bots hitting your
> server
> all the time (I've seen a case where a security scanner crashed an app
> because of its poor exception/ non-existent page handling).
>
> Kalle
>
>
> On Thu, Aug 28, 2008 at 4:36 AM, Geoff Callender <
> geoff.callender.jumpstart@gmail.com> wrote:
>
>> Thanks, Howard.
>>
>> Surely someone has an opinion on which approach is best?!?!
>> Suggestions,
>> please.
>>
>> Geoff
>>
>>
>> On 27/08/2008, at 9:18 AM, Howard Lewis Ship wrote:
>>
>> Don't forget about the "exception" event that allows a page to handle
>>> its own exceptions before they are passed off to the
>>> RequestExceptionHandler service.
>>>
>>> On Tue, Aug 26, 2008 at 3:12 PM, Geoff Callender
>>> <ge...@gmail.com> wrote:
>>>
>>>> I'm looking for thoughts on the best way to handle this situation
>>>> that
>>>> almost every page has to deal with.
>>>>
>>>> Let's say the user chose http://myhost/myapp/products/123, so the
>>>> Products
>>>> page tries to get product 123 in onActivate. What if the product
>>>> doesn't
>>>> exist, or the user is not authorised to view the product? I see 3
>>>> options:
>>>>
>>>> 1. Handle it on the same page - either display the product or
>>>> display the
>>>> error, on the same page.
>>>> 2. Return a new page, possibly setting it up with a message.
>>>> 3. Throw an exception and interpret it in your app's exception
>>>> page. The
>>>> exception page could give certain exceptions special treatment eg.
>>>> DoesNotExistException and NotAuthorisedException might get
>>>> different
>>>> treatment to unexpected exceptions.
>>>>
>>>> Approach 1 has the big advantage that it keeps the same URL - the
>>>> user
>>>> can
>>>> see what they requested.
>>>> Approach 2 gives you complete control over the page they see but
>>>> the user
>>>> can no longer see the URL they requested.
>>>> Approach 3 is really simple to implement.
>>>>
>>>> Are there other considerations? Is one of these more RESTful?
>>>>
>>>> Cheers,
>>>> Geoff
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator Apache Tapestry and Apache HiveMind
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Invalid requests - best practice?
Posted by Kalle Korhonen <ka...@gmail.com>.
JMHO, but I think it depends on the case. In your product example, I'd let
the page itself handle the error since it's relatively clear the user tried
to access a non-existent (possibly removed or non-authorized) product. For a
completely random, non-existent url, I'd try to handle it as soon as
possible with a generic 404 page. Throwing exceptions is expensive,
especially on open web there will be crawlers and bots hitting your server
all the time (I've seen a case where a security scanner crashed an app
because of its poor exception/ non-existent page handling).
Kalle
On Thu, Aug 28, 2008 at 4:36 AM, Geoff Callender <
geoff.callender.jumpstart@gmail.com> wrote:
> Thanks, Howard.
>
> Surely someone has an opinion on which approach is best?!?! Suggestions,
> please.
>
> Geoff
>
>
> On 27/08/2008, at 9:18 AM, Howard Lewis Ship wrote:
>
> Don't forget about the "exception" event that allows a page to handle
>> its own exceptions before they are passed off to the
>> RequestExceptionHandler service.
>>
>> On Tue, Aug 26, 2008 at 3:12 PM, Geoff Callender
>> <ge...@gmail.com> wrote:
>>
>>> I'm looking for thoughts on the best way to handle this situation that
>>> almost every page has to deal with.
>>>
>>> Let's say the user chose http://myhost/myapp/products/123, so the
>>> Products
>>> page tries to get product 123 in onActivate. What if the product doesn't
>>> exist, or the user is not authorised to view the product? I see 3
>>> options:
>>>
>>> 1. Handle it on the same page - either display the product or display the
>>> error, on the same page.
>>> 2. Return a new page, possibly setting it up with a message.
>>> 3. Throw an exception and interpret it in your app's exception page. The
>>> exception page could give certain exceptions special treatment eg.
>>> DoesNotExistException and NotAuthorisedException might get different
>>> treatment to unexpected exceptions.
>>>
>>> Approach 1 has the big advantage that it keeps the same URL - the user
>>> can
>>> see what they requested.
>>> Approach 2 gives you complete control over the page they see but the user
>>> can no longer see the URL they requested.
>>> Approach 3 is really simple to implement.
>>>
>>> Are there other considerations? Is one of these more RESTful?
>>>
>>> Cheers,
>>> Geoff
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Invalid requests - best practice?
Posted by Geoff Callender <ge...@gmail.com>.
Thanks, Howard.
Surely someone has an opinion on which approach is best?!?!
Suggestions, please.
Geoff
On 27/08/2008, at 9:18 AM, Howard Lewis Ship wrote:
> Don't forget about the "exception" event that allows a page to handle
> its own exceptions before they are passed off to the
> RequestExceptionHandler service.
>
> On Tue, Aug 26, 2008 at 3:12 PM, Geoff Callender
> <ge...@gmail.com> wrote:
>> I'm looking for thoughts on the best way to handle this situation
>> that
>> almost every page has to deal with.
>>
>> Let's say the user chose http://myhost/myapp/products/123, so the
>> Products
>> page tries to get product 123 in onActivate. What if the product
>> doesn't
>> exist, or the user is not authorised to view the product? I see 3
>> options:
>>
>> 1. Handle it on the same page - either display the product or
>> display the
>> error, on the same page.
>> 2. Return a new page, possibly setting it up with a message.
>> 3. Throw an exception and interpret it in your app's exception
>> page. The
>> exception page could give certain exceptions special treatment eg.
>> DoesNotExistException and NotAuthorisedException might get different
>> treatment to unexpected exceptions.
>>
>> Approach 1 has the big advantage that it keeps the same URL - the
>> user can
>> see what they requested.
>> Approach 2 gives you complete control over the page they see but
>> the user
>> can no longer see the URL they requested.
>> Approach 3 is really simple to implement.
>>
>> Are there other considerations? Is one of these more RESTful?
>>
>> Cheers,
>> Geoff
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Invalid requests - best practice?
Posted by Howard Lewis Ship <hl...@gmail.com>.
Don't forget about the "exception" event that allows a page to handle
its own exceptions before they are passed off to the
RequestExceptionHandler service.
On Tue, Aug 26, 2008 at 3:12 PM, Geoff Callender
<ge...@gmail.com> wrote:
> I'm looking for thoughts on the best way to handle this situation that
> almost every page has to deal with.
>
> Let's say the user chose http://myhost/myapp/products/123, so the Products
> page tries to get product 123 in onActivate. What if the product doesn't
> exist, or the user is not authorised to view the product? I see 3 options:
>
> 1. Handle it on the same page - either display the product or display the
> error, on the same page.
> 2. Return a new page, possibly setting it up with a message.
> 3. Throw an exception and interpret it in your app's exception page. The
> exception page could give certain exceptions special treatment eg.
> DoesNotExistException and NotAuthorisedException might get different
> treatment to unexpected exceptions.
>
> Approach 1 has the big advantage that it keeps the same URL - the user can
> see what they requested.
> Approach 2 gives you complete control over the page they see but the user
> can no longer see the URL they requested.
> Approach 3 is really simple to implement.
>
> Are there other considerations? Is one of these more RESTful?
>
> Cheers,
> Geoff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org