-------- Original Message -------- Subject: Re: Mozilla http post intercept Date: Wed, 28 Aug 2002 11:48:38 -0700 From: Darin Fisher <[EMAIL PROTECTED]> To: Wesley W. Terpstra <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]>
Wesley W. Terpstra wrote: >Hey, I have noticed that you own: > netwerk/protocol/http/public/nsIHttpNotify.idl >so I wanted to ask a few questions. > >If I wanted to read the POST data being sent out on all HTTP POSTs, would >the correct thing to do be: > 1. Make an object implementing nsIHttpNotify.idl > 2. In the onModifyRequest method of my object, read the uploadStream > beware that the uploadStream may contain some HTTP headers (usually Content-Length and Content-Type) followed by a new-line before the actual POST data appears. > 3. use readSegments to examine the stream without consuming it > ReadSegments will only show you the first segment of the buffer. You'd have to consume data to advance to the next segment. But, that's not a problem because nsIHttpChannel::uploadStream is required to implement nsISeekableStream, so you can easily read the stream and then rewind it to the beginning. > 4. Somehow register my object to intercept the requests >? > you can do this the same way nsCookieHTTPNotify registers itself. look for the methods call RegisterProc and UnregisterProc in nsCookieHTTPNotify.cpp. then notice how they are mentioned in nsModuleFactory.cpp. > >I particullarily want to know about step 4, and what to do if step 3 is >impossible because the readSegments in unimplemented. > >Are there any boundary conditions I should be wary of? > no, just be sure that if you want to replace the uploadStream (via nsIUploadChannel) that you pass an object that also implements nsISeekableStream, or else the upload request may sometimes fail. also, session history (the thing that manages back/forward) remembers the original POST data generated by the form submission code. so, if the user presses back to visit a page that resulted from a form submission, and the resulting page has been evicted from the cache, then the POST request may be replayed (this must be approved by the user) and your code will still work. but, there is probably not an easy way for you to replace the POST data stream that session history remembers. > >Also, if after reading the content, I concluded that the POST should not be >sent, could I terminate it? > yes, you can call the Cancel method; however, this code path has not been tested, and when i look at the code, it appears to me that the request would still get sent to the server, but then would be canceled once the server started to respond to the POST request. so, that may or may not work for you application. if it doesn't, then file a bug and it should be trivial to make it immediately cancel the http channel instead. Darin
