Get strange 404 delivered

I occasionally receive a 404 http status code from my REST handler. I don't send 404 myself and the only possibility I've found is if WARestfulhandler>>handleFiltered: does not find a route and calls noRouteFound: which sends a 404. This problem I had some times if I forget to deliberately respond the http connection myself. But in this case it is different. My setup is as following:

I have a dummy WARestfulHandler that does nothing but gets attached as handler. All of the layered functionality is added as a filter. In order to send the proper error and to get an objectlog entry I have

        exceptionFilter := WAExceptionFilter new.
  exceptionFilter configuration addParent: WAAdmin applicationExceptionHandlingDefaults.
        ...
        (WAAdmin register: self at: 'myhandler')
                addFilterFirst: exceptionFilter;
                addFilter: otherFilter
                ...

In the troublesome REST handler I have

        ...
        [
                [
                        [
                                commandList validate.
          commandList execute
                        ] on: MMFieldVersionError, MMObjectNotInCollectionError, MMGlobalReferenceError, MMObjectNotFound
                          do: [:err|  
                                        self abortTransaction.
                                        self sendErrorStatus: 409 withText: err messageText ]
                ] on: MAError, MMLocalReferenceError
                        do: [:err|
                                self abortTransaction.
                                self sendClientError: err messageText]
        ] on: Error
                do: [:err|  
                        self abortTransaction.
                        err signal ].

The error that occurs is one that is not catched by the first on:do:. I'm not sure if I need the last one at all but this should work as I would expect it, right? The error is catched and the transaction aborted. The exception is resignalled and catched by the WAExceptionFilter which adds an objectlog entry and sends a 500 error. Adding to the object log works for other errors. I just get a 404 error and that is strange. Probably there is something I do wrong in the combination of transaction and exception handling. If you have any ideas what code go wrong that would fine.

thanks,

Norbert

Norbert,

In Bibliocello, I added the RESTful  filter first, then implemented the noRouteFound: method to do:

  noRouteFound: aRequestContext
    self next handleFiltered: aRequestContext

Which has the effect of passing the request along to the session "filter" if no route is found ...

If you are getting a 404, then the default noRouteFound: method must be executing ... presumably you can set a halt, breakpoint or log a continuation in that method to learn more about how you are getting there...

When you are talking about Errors are you implying that the noRouteFound: method is triggered by an Error?

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, July 27, 2011 4:56:45 AM
| Subject: [GS/SS Beta] Get strange 404 delivered
|
| I occasionally receive a 404 http status code from my REST handler. I
| don't send 404 myself and the only possibility I've found is if
| WARestfulhandler>>handleFiltered: does not find a route and calls
| noRouteFound: which sends a 404. This problem I had some times if I
| forget to deliberately respond the http connection myself. But in
| this case it is different. My setup is as following:
|
| I have a dummy WARestfulHandler that does nothing but gets attached
| as handler. All of the layered functionality is added as a filter.
| In order to send the proper error and to get an objectlog entry I
| have
|
| exceptionFilter := WAExceptionFilter new.
|   exceptionFilter configuration addParent: WAAdmin
|   applicationExceptionHandlingDefaults.
| ...
| (WAAdmin register: self at: 'myhandler')
| addFilterFirst: exceptionFilter;
| addFilter: otherFilter
| ...
|
| In the troublesome REST handler I have
|
| ...
| [
| [
| [
| commandList validate.
| commandList execute
| ] on: MMFieldVersionError, MMObjectNotInCollectionError,
| MMGlobalReferenceError, MMObjectNotFound
| do: [:err|
| self abortTransaction.
| self sendErrorStatus: 409 withText: err messageText ]
| ] on: MAError, MMLocalReferenceError
| do: [:err|
| self abortTransaction.
| self sendClientError: err messageText]
| ] on: Error
| do: [:err|
| self abortTransaction.
| err signal ].
|
| The error that occurs is one that is not catched by the first on:do:.
| I'm not sure if I need the last one at all but this should work as I
| would expect it, right? The error is catched and the transaction
| aborted. The exception is resignalled and catched by the
| WAExceptionFilter which adds an objectlog entry and sends a 500
| error. Adding to the object log works for other errors. I just get a
| 404 error and that is strange. Probably there is something I do
| wrong in the combination of transaction and exception handling. If
| you have any ideas what code go wrong that would fine.
|
| thanks,
|
| Norbert
|
|

Am 27.07.2011 um 19:29 schrieb Dale Henrichs:

> Norbert,
>
> In Bibliocello, I added the RESTful  filter first, then implemented the noRouteFound: method to do:
>
>  noRouteFound: aRequestContext
>    self next handleFiltered: aRequestContext
>
Hmmm. I don't get how this is supposed to work. I assume the first filter is first in processing. The WAExceptionFilter wraps further process in an exception handling block. Don't have to put it before the actual rest handler to have exception caught?

> Which has the effect of passing the request along to the session "filter" if no route is found ...
>
What is the session "filter"?

> If you are getting a 404, then the default noRouteFound: method must be executing ... presumably you can set a halt, breakpoint or log a continuation in that method to learn more about how you are getting there...
>
Yes, I was just asking upfront because my test server is not in place, yet. And the code I'm talking about is live.

> When you are talking about Errors are you implying that the noRouteFound: method is triggered by an Error?
>
Yes. That is exactly the problem I'm trying to figure out. I suspected the resignal could do any harm but removing it does not change the effect.

Norbert

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, July 27, 2011 2:20:33 PM
| Subject: Re: [GS/SS Beta] Get strange 404 delivered
|
|
| Am 27.07.2011 um 19:29 schrieb Dale Henrichs:
|
| > Norbert,
| >
| > In Bibliocello, I added the RESTful  filter first, then implemented
| > the noRouteFound: method to do:
| >
| >  noRouteFound: aRequestContext
| >    self next handleFiltered: aRequestContext
| >
| Hmmm. I don't get how this is supposed to work. I assume the first
| filter is first in processing. The WAExceptionFilter wraps further
| process in an exception handling block. Don't have to put it before
| the actual rest handler to have exception caught?

I'm not completely sure what I did for error handling in Bibliocello, but I think the idea here is that if there is no REST mapping for the request just pass it along the next filter in line ... Bibliocello has Pier so, if the request is not RESTful, then I wanted Pier to have a chance to handle the request and I assume that `next handleFiltered:` did the job ... It does look like the exception filter moves along the the line wrapping the following entries with the error handler...However...

...If you are getting a 404, then you must not have implemented noRouteFound: or one of the several other places in Seaside where 404 are generated could be the source ... they are all of the flavor of the noRouteFound ...

I think it is more likely that it is _not_ exception handling but incorrect logic in the filter chain that is the source of your 404...

Dale

|
| > Which has the effect of passing the request along to the session
| > "filter" if no route is found ...
| >
| What is the session "filter"?
|
| > If you are getting a 404, then the default noRouteFound: method
| > must be executing ... presumably you can set a halt, breakpoint or
| > log a continuation in that method to learn more about how you are
| > getting there...
| >
| Yes, I was just asking upfront because my test server is not in
| place, yet. And the code I'm talking about is live.
|
| > When you are talking about Errors are you implying that the
| > noRouteFound: method is triggered by an Error?
| >
| Yes. That is exactly the problem I'm trying to figure out. I
| suspected the resignal could do any harm but removing it does not
| change the effect.
|
| Norbert
|
| >
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Wednesday, July 27, 2011 4:56:45 AM
| > | Subject: [GS/SS Beta] Get strange 404 delivered
| > |
| > | I occasionally receive a 404 http status code from my REST
| > | handler. I
| > | don't send 404 myself and the only possibility I've found is if
| > | WARestfulhandler>>handleFiltered: does not find a route and calls
| > | noRouteFound: which sends a 404. This problem I had some times if
| > | I
| > | forget to deliberately respond the http connection myself. But in
| > | this case it is different. My setup is as following:
| > |
| > | I have a dummy WARestfulHandler that does nothing but gets
| > | attached
| > | as handler. All of the layered functionality is added as a
| > | filter.
| > | In order to send the proper error and to get an objectlog entry I
| > | have
| > |
| > | exceptionFilter := WAExceptionFilter new.
| > |   exceptionFilter configuration addParent: WAAdmin
| > |   applicationExceptionHandlingDefaults.
| > | ...
| > | (WAAdmin register: self at: 'myhandler')
| > | addFilterFirst: exceptionFilter;
| > | addFilter: otherFilter
| > | ...
| > |
| > | In the troublesome REST handler I have
| > |
| > | ...
| > | [
| > | [
| > | [
| > | commandList validate.
| > | commandList execute
| > | ] on: MMFieldVersionError, MMObjectNotInCollectionError,
| > | MMGlobalReferenceError, MMObjectNotFound
| > | do: [:err|
| > | self abortTransaction.
| > | self sendErrorStatus: 409 withText: err messageText ]
| > | ] on: MAError, MMLocalReferenceError
| > | do: [:err|
| > | self abortTransaction.
| > | self sendClientError: err messageText]
| > | ] on: Error
| > | do: [:err|
| > | self abortTransaction.
| > | err signal ].
| > |
| > | The error that occurs is one that is not catched by the first
| > | on:do:.
| > | I'm not sure if I need the last one at all but this should work
| > | as I
| > | would expect it, right? The error is catched and the transaction
| > | aborted. The exception is resignalled and catched by the
| > | WAExceptionFilter which adds an objectlog entry and sends a 500
| > | error. Adding to the object log works for other errors. I just
| > | get a
| > | 404 error and that is strange. Probably there is something I do
| > | wrong in the combination of transaction and exception handling.
| > | If
| > | you have any ideas what code go wrong that would fine.
| > |
| > | thanks,
| > |
| > | Norbert
| > |
| > |
|
|