[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Experimental C unit test suite available for hacking

On Thu, May 31, 2018 at 10:07 AM, Yann Ylavic <ylavic.dev@xxxxxxxxx> wrote:
On Thu, May 24, 2018 at 8:11 PM, William A Rowe Jr <wrowe@xxxxxxxxxxxxx> wrote:
> On Thu, May 24, 2018, 06:34 Eric Covener <covener@xxxxxxxxx> wrote:
>> Despite the directory structure, this was not part of a "module" in
>> the httpd/LoadModule sense.  I think it's reasonable to pull it "up"
>> which is simpler then trying to push more stuff down into
>> modules/http/.
> [Caviet]
> Note that relocation is a major mmn bump, due to two level namespaces...
> Which isn't usual apparent on flat namespace architectures such as Linux.

How about:
1. we move+rename the functions to "server/protocol.c" and have and
the "modules/http/http_etag.c" ones simply call the formers (MINOR
2. we then "svn remove" modules/http/http_etag.c and rename back
ap_make_etag_core() and ap_set_etag_core() to their original names
(MAJOR bump, both for namespace and removal of transient _core()

That way 1. would be backportable to 2.4.x, and after 2/ trunk in the
state we want it to be.
Does it sound good?

That's entirely workable. We just can't change the exports by-module
during the 2.4.* cycle, and the proposal above accomplishes this (but
does make backports more of a headache during that transition.)
As long as the users' code compiles and links against 2.5.* you have
not broken anything, so long as they don't need to change #include's.

It would be nice to have a schematic of where stuff belongs. http2_*
family modules should obviously have those transport-only semantics. 
Perhaps evolve transport-only HTTP 1.x http_* semantics into an
http1_* module, for easy discard.

We could keep mod_http(_*) for all HTTP/*.* protocol encoding, but
seeing as this is the httpd server, putting any protocol encoding logic
into core (perhaps later into a libhttpd, e.g. http_etag -> util_etag)
seems rational.