[Twisted-Python] breaking distrib.ResourceSubscription
Glyph Lefkowitz
glyph at twistedmatrix.com
Tue Sep 24 20:28:33 EDT 2002
On 24 Sep 2002 15:11:41 -0700, Kevin Turner <acapnotic at twistedmatrix.com> wrote:
> On Tue, 2002-09-24 at 06:57, Glyph Lefkowitz wrote:
> [...]
> > ResourcePublisher instance has no attribute 'remote_wasModifiedSince'
>
> I'm surprised that this is in the logs much, since it should only happen
> for distributed servers that set a Last-Modified header. Are personal
> servers serving that many static files? I would have thought that would
> be handled by ~/public_html.
The tracebacks I was seeing were for wikis and viewcvs; either moin is setting
those headers or it's serving the images / static data from a personal server
directory.
> > I thought that I'd mentioned this over IRC before, but let me stress it: I
> > think that twisted.web.server is implementing *WAAAAY* too much of HTTP right
> > now.
>
> Interesting position. I know you're not a fan of complete support for a
> protocol when you believe the protocol itself is broken, and I'll admit
> that nobody actually uses ETags, but I would hardly say that
> Last-Modified and HEAD are obscure or unnecessary.
Nor would I. After much discussion with itamar I conceded that HEAD ought to
cause the body of the request to be eaten there before being sent to the
client.
What I mean here is that the actual module, twisted.web.server, is being too
smart about stuff like Last-Modified and ETags. HTTP should be fully
implemented, but parts of the responsibility lie elsewhere.
twisted.web.Resource subclasses can implement those themselves if they want to,
because the 99.9% cases should be handled: static.File will handle filesystem
content and woven.* will handle dynamic content. We can also provide a helper
for mix-in that does conditional-rendering stuff.
> > First of all, this is killing performance -- you have a minimum of 4 or 5
> > PB server/client interactions now for each conditional request instead of 2.
> > Those method calls are not cheap.
>
> Recognized. Although I thought I only increased the count by one, not
> two or three?
Looking at it now, I guess ETags and last-modified support are exclusive. (Is
this correct, protocol-wise?) However, each call that requires an answer is
minimum of 2 interactions (request/response). Plus most resources will want to
do a .write().
> Also take into consideration that these calls only happen for the
> *conditional* requests.
The only heuristic I have for how often these happen are the once-per-minute
tracebacks I was seeing while bots were crawling the website yesterday. So it
looked quite often. :)
> > Second, this is exploding the complexity of the webserver: its goal should
> > be to get to the endpoint resource *as simply as possible* and then invoke
> > endpoint behavior on that resource. If clever header-parsing things need
> > to happen, then we need to make a lower-level 'request' method and make
> > *it* clever, not do request processing before the request is dispatched.
> This I agree with. I knew something was wrong when I had three remote
> methods in ResourcePublisher all independently doing getResourceFor. It
> would be more symmetric if Request.process was invoked on the distri --
Right. :-)
> ggrngh. What is Request.process anyway. Is it just supposed to do
> site.getResourceFor and pass itself off? Yes. All the rest of the junk
> in there is stuff I added (though the HEAD/supportedMethods stuff was
> quite some time ago) with the possible exception of the
> util.Unauthorized block. And it's probably all logic that belongs in
> web..Resource rather than Request.
HEAD definitely ought to still have a little bit of logic in Request, since it
should discard any body that the resource attempts to return. However, the
rest of what you're saying is definitely...
> ([...] just re-iterating what you've been telling me.)
> So how do we fix it? You're suggesting that Request.process call
> Resource.request, which contains most of the stuff currently in
> Request.process, and Resource.request calls Resource.render if it's not
> a conditional request?
See above for my suggestion. I think that Resource is too low-level for this
sort of thing (since the default implementation of wasModifiedSince is going to
be 'return 1', why invoke it at all by default?). I don't feel strongly that
my suggestion is better than this one though, if you think that dynamic
resource implementors are going to want to use this functionality a lot.
(Thoughts, Donovan?)
> Sounds like we need an inter-version test harness. Runs peer1 under
> version X and peer2 on Y, or starts server on version X, pickles it, and
> re-starts under Y, etc.
Yes. This is something that I think radix hacked up manually a little while
back, but it needs to be added to accepttests.
Sounds like we're in general agreement, then...
--
| <`'> | Glyph Lefkowitz: Traveling Sorcerer |
| < _/ > | Lead Developer, the Twisted project |
| < ___/ > | http://www.twistedmatrix.com |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20020924/879e7dc8/attachment.pgp
More information about the Twisted-Python
mailing list