Without analysing the code further, it appears the parser tries all that it can to continue parsing the cookie string and fails when it doesn't have any other option.
I guess you could try re-writing it in completely different way if you wanted a more controllable mechanism. Regards, Peter On 11/02/2011, at 1:16 PM, Dov Rosenberg wrote: > Is there any way to just skip over the bad cookies and continue on - i.e. > Like if the malformed cookie is the third out of 5 cookies > > Thanks > > Dov Rosenberg > > > On 2/10/11 8:35 PM, "Peter Vandoros" <[email protected]> wrote: > >> "Debugging" _WOCookieParser, an IllegalStateException is thrown when it >> encounters a problem. The exception is caught and >> WOApplication.application().handleMalformedCookieString() is called. in >> WOApplication.application().handleMalformedCookieString(), the initialisation >> parameter is checked and then returns the NSDictionary of already parsed >> cookies (if parameter set to true). >> >> This confirms that it does quit processing subsequent cookies on the first >> error encountered :) >> >> Regards, >> >> Peter >> >> On 11/02/2011, at 12:21 PM, Tom M. Blenko wrote: >> >>> >>> I had the flag running in production on one site for a couple of years (same >>> situation you mention) with no problems - I don't believe it just quits >>> parsing on a single error but I don't know. You might want use >>> WOApplication.handleMalformedCookieString(), which returns cookies >>> successfully parsed, if you want to check it out further or try to better >>> recovery yourself. >>> >>> Tom >>> >>> >>> On Feb 10, 2011, at 4:30 PM, Peter Vandoros wrote: >>> >>>> With the initialisation parameter you mention, I believe the CookieParser >>>> will stop parsing subsequent cookies once it encounters a malformed one. >>>> This means that if the malformed cookie happens to be the first one, as >>>> sent >>>> by the user's browser, then you application won't receive any subsequent >>>> cookies. This will obviously break the WO session handling via cookies. >>>> >>>> I'm not sure what to do other than "write" your own _CookieParser :) >>>> >>>> Regards, >>>> >>>> Peter >>>> >>>> On 11/02/2011, at 7:14 AM, Dov Rosenberg wrote: >>>> >>>>> We came across a strange issue that took a bit to figure out but thought >>>>> it >>>>> would be worthwhile to let everyone else know what happened >>>>> >>>>> Problem >>>>> Some users were having trouble saving a form (WOComponent based) >>>>> intermittently. Normally these kinds of problems are nearly impossible to >>>>> figure out unless you get lucky. We got lucky. >>>>> >>>>> Root Cause >>>>> Looking thru the log files we saw a handful of error messages that looked >>>>> like >>>>> >>>>> 410901380 [http-8228-Processor2] WARN er.extensions.appserver.ERXRequest >>>>> - >>>>> java.lang.IllegalStateException: Malformed cookie content: >>>>> >>>>> The default OOTB behavior of WebObjects is to throw an exception when a >>>>> malformed cookie is detected in the HTTP Request. This disrupts the normal >>>>> HTTP request/response loop which played hell with our WOComponent. >>>>> >>>>> The malformed cookie was being set by another web site in their domain >>>>> that >>>>> was using Google Analytics. Not sure what the problem was with the cookie >>>>> – >>>>> saw one that URL encoded 4 times over and another with a null value. >>>>> >>>>> Solution >>>>> Thankfully the WO folks realized that throwing an exception while >>>>> processing cookies might be a bad thing (default behavior) that they added >>>>> an initialization parameter to change the default behavior to something >>>>> more sensible. By setting WOAcceptMalformedCookies=true all cookies will >>>>> be >>>>> accepted but the malformed ones will be dropped and not processed. After >>>>> changing the default behavior our app stopped misbehaving. >>>>> >>>>> Not sure if changing the default behavior is a good thing from a security >>>>> perspective but it did resolve the error for us. Anyone have any thoughts >>>>> on the impact of this change? >>>>> >>>>> Dov Rosenberg >>>>> InQuira >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/peter.vandoros%40gmai >>>>> l.com >>>>> >>>>> This email sent to [email protected] >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/blenko%40martingalesys >>>> tems.com >>>> >>>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/peter.vandoros%40gmail. >>> com >>> >>> This email sent to [email protected] >> > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
