From: Aredridel <aredridel@...>
Date: 2004-08-28T10:16:26+09:00
Subject: Re: Separation of Web Request and Response (was: Re: Idea:	Webshare)

> There are in fact good reasons in favor of the request / response split.
> First of all request and response are in fact two different things, so from
> that point of view it's not a bad idea to separate them.  The interface of a
> combined request response instance is likely to get too bloated.  There are
> use cases where you only need the response (say, a page that displays the
> current time) and there might be others where you don't need the response
> (can't think of any at the moment though, some kind of upload maybe :-)).

Well, all HTTP requests have responses, though some are pretty spartan
(302, for example)

There's basically two models at work here: the servlet-ish model, with
separation, and the apache request-cycle model, without.

I don't see them as contradictory, particularly. They're two views of
the same thing, eventually.

Apache has "handlers", each of which can snoop on the request at that
moment and tweak it as neccesary for later handlers to get. Its stacking
makes having one, big, durable object that persists the whole cycle
valuable: one can look back on the whole cycle for information on what
to do.

The request-response split also makes sense: they're very different in
some ways. A request has a method, a path, some headers and a body. The
response has a status code, headers, and sometimes a body. It seems a
perfect place to put some inheritance, since there's some shared
implementation (headers and body), and some specific things to each.

> Another reason why I liked the separation (in Java) is that you can easily
> wrap only one of them (common with filters in Java, but similar things can
> be done with Ruby, too); examples are filtering of whitespace from the
> response and adding default values for request parameters.  If request and
> response are encapsulated in a single instance this becomes much more
> difficult to do - and the fun goes away. :-)

Not terribly, actually: in Java, you wrap; in Apache-style, you just
modify in place. (The analogy with gsub() and gsub!() is apparent to me,
at least)

I like the split, since I think all possibilities are available to both.
In one, one gets a req and a resp passed to the method; in the other,
you get req. In one, you have req.body and resp.body, the other is
req.request_body and req.response_body. I think the first is much
cleaner.

What really needs to happen is documentation of the request and response
cycle, and if filters need to happen, document how to add them, and what
hooks are available.

I think the real question is "what use cases are there for hooks,
handlers and filters?".  I see several:

	* Filters (ala aspect programming), both header-filters for security,
and body content filters for content adjustment (XHTML2 -> XHTML1.1 for
example)
	* Additional file-type handlers (potentially for .erb, for .cgi, for
fast cgi, possibly.)[1]
	* Implement additional HTTP methods (PUT, DELETE, PROPFIND like DAV)

And then there's the question of how to implement that with the
mountpoint-oriented structure of something like webrick.[2]

Ari
	

[1] Don't let me start on "file extension" based dispatch. I don't like
it at all.

[2] Personally, I like WEBrick a lot. Nice simple structure.