Alex, I've removed the recycling mechanism because it causes potential issues with private variables in parent classes (HttpServerCall and HttpCall).
Best regards, Jerome > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la > part de Alex Milowski > Envoyé : jeudi 16 août 2007 01:36 > À : discuss@restlet.tigris.org > Objet : Critical Patch for Grizzy Connector > > I figured out why I was having troubles with the Grizzy > connector. It pools the > instances of GrizzyServerCall but doesn't clear the headers. As such, > previous random > headers remain in the call! > > In my case, there were two Authorization headers and the parser uses > getValues() on > the Series<Parameter> instance. As such, the credential parser fails > (which is why > the base64 decoding fails too). That was the previous fix for the > null pointer exception. > > Here is the patch that fixes this issue: > > Index: GrizzlyServerCall.java > =================================================================== > --- GrizzlyServerCall.java (revision 2136) > +++ GrizzlyServerCall.java (working copy) > @@ -86,6 +86,7 @@ > headStream.setSelectionKey(key); > headStream.setByteBuffer(byteBuffer); > this.socketChannel = (SocketChannel) key.channel(); > + this.getRequestHeaders().clear(); > > // Read the request header > readRequestHead(headStream); > > > Now, I suspect there may be other problems with pooling calls but I > have reviewed the > code in detail. > > I'd apply this patch ASAP because it is a serious security flaw as a > previous Authorization > header could remain and randomly allow another user into a resource > for which they > do not have access. > > --Alex Milowski
