Request/Reply doesn't have enough methods for Filters.

Alexandre Rafalovitch writes:
 > Hi,
 > 
 > I am trying to extend DebugFilter to trace information flow in mine and
 > supplied Resource classes. However, I have problems with it, because there
 > are not enough methods to expose this information.
 > 
 > For example, I am trying to debug LastModifyed / IfModifiedSince
 > interaction and for this purpose I need to dump their values from
 > Request/Reply corresponding headers. Now I am able to dump 'If modified
 > Since' header by using getIfModifiedSince() method of Request (or dump in
 > MIMIHeaders as it might be). However, I see no way to access LastModified
 > information in Reply.
 > I do not want to modify Library Reply class and recompile it, so what
 > options do I have left?

Well, you can safely add this one to the repy class:

public long getLastModify() {
	if ( (set & LAST_MODIFIED_BIT) == 0 ) 
	    throw new HTTPRuntimeException(this
					   , "getLastModify"
					   , "no date set.") ;
        return this.last_modified;
}

This method will be there in the next version of the Request/Reply
APIs. It's not there because I just never need it...

 > On a general note, Request class does not allow to set headers, even though
 > I can probably get around it by using defineField and getField in
 > MIMEHeaders class. Reply, on the other hand; does not have even that much,
 > and does not give out any information except for content* and status.

Yep, Reply needs some reworking to get this extensibility problem
fixed. BTW for Request, defineField and getField were intended to play
this role.

 > What would I have to do if I wanted to use my filters to modify headers on
 > the way in and out. Or if I wanted to log all redirects and record referer
 > who was pointing to old place, etc.. I really don't see a way to do that
 > now as a filter on resource, not part of resource itself.

You are correct, the redesign in the way is much more rational (each
field has both a getter and a setter, etc.) It should also be much
more efficient.

 > Comments anybody? If I am right it  _might_  require 6th redesign Anselm
 > was talking about.


The redesign only affects the Reply / Request internals, as I said, I
hope to be able to do this without changing the rest of the world...

Anselm.

Received on Friday, 21 June 1996 18:56:00 UTC