Ceph's custom apache: ok to drop?

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

 



Hi folks,

The Apache fork that we ship on Ceph.com
(https://github.com/ceph/apache2) is several versions behind upstream
and has a couple CVEs by now.

I've heard from the developers (I don't remember if it was Dan, Yehuda,
or someone else) refer on IRC to the idea that the changes in our Ceph
Apache fork were cosmetic, and it's ok to simply use upstream Apache.

I wanted to confirm this with a wider audience: it's ok to stop
maintaining and shipping our custom Apache?

In other words, we would remove references to our custom Apache from
Teuthology, and our docs, and eventually from our repositories?


-----

Diving into our changes, there are two patches that we have on top of
Apache 2.2.22:

1. "rgw: don't unset Content-Length header on HEAD response (this was
being done when content length was 0)"
https://github.com/ceph/apache2/commit/5ae1b4a081b05fcacf55e7114eec87d9b2a0a5da
. (See also the original patch submission at
http://tracker.ceph.com/issues/897)

2. "don't complain on badly formatted expectations"
https://github.com/ceph/apache2/commit/0d9948f1e483386adef0841896484db8422127b2

Both of these were submitted to Apache upstream in December 2013 (thread
on apache-dev "Ceph patches for httpd") and merged in
http://svn.apache.org/r1554303 .

So his will be controllable via new directives in httpd 2.5:
"HttpContentLengthHeadZero" (defaults to off, ie, continue to squelch
the zero-length header) and HttpExpectStrict (defaults to off, ie,
continue to log the error).

So for httpd 2.5 we have something that gives us what we need.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux