On Fri, Aug 29, 2008 at 2:37 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 29, 2008 at 2:28 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > There are many things that need rewriting that don't involve an HTTP > fetch > > (how would you model variable substitution or html wrapper appending in a > > rewriter that is operating on an HttpRequest?) > > Shared libraries. Some code would handle rewriting a GadgetSpec > object, other code would handle rewriting an HttpResponse, and both > would rely on the same underlying libraries. The current rewriter already does exactly what you just described -- the problem is that it's doing it in the HTTP caching pipeline, where it doesn't belong. > > Rewriting should be rewriting, HTTP fetching should be HTTP fetching, and > > caching should be caching. Trying to make everything look like HTTP > requests > > has caused nothing but problems over the last few months, and we should > not > > continue down that path. > > > We need rewriting to plug into both gadgets/makeRequest and > gadgets/ifr, apparently. Are there other places? How should we plug > them in? > That's what the rewriting interface is for. There are a couple of other threads going discussing the rewriter. The best place to do rewriting is going to be in the place where we have all the needed context for doing it. That means: - In GadgetRenderingTask (soon to be "Renderer"), for rewriting gadgets. - In MakeRequestHandler, for makeRequest. - In ProxyHandler, for the open proxy. The last two might be able to get rolled into ProxyBase, but that's unlikely since makeRequest and proxied requests are substantially different. When you're doing the rewriter at the HTTP request level, it requires pulling in a ton of context way down deep into the stack. That doesn't work for many reasons.
