Bruno's questions

A servlet engine (Jetty) is running behind an Apache Httpd server, forwarded using mod_proxy_http. This is running a small servlet that accepts PUT requests and is authenticated using HTTP Basic authentication (handled within Jetty).

When doing a direct (non-proxied) PUT request with curl, using the wrong authentication credentials, the server returns a 401 status code as expected:

curl -v -T testfile -u user:WRONG_PASSWORD http://localhost:8080/myservlet/

This interrupts the requests as soon as the status code is received, so curl doesn't upload the whole body, but stops early (HTTP error before end of send, stop sending).

* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
* Server auth using Basic with user 'user'
> PUT /myservlet/testfile HTTP/1.1
> Authorization: Basic xxxxxxxxxxxxxxxxx
> User-Agent: curl/7.22.0
> Host: localhost:8080
> Accept: */*
> Content-Length: 3672
> Expect: 100-continue
> 
< HTTP/1.1 401 Unauthorized
< Date: xxxxxxxxxxxxxxxx
* Authentication problem. Ignoring this.
< WWW-Authenticate: basic realm="Test Realm"
< Content-Length: 0
< Server: Jetty(7.4.5.v20110725)
* HTTP error before end of send, stop sending
< 
* Closing connection #0

In contrast, when behind mod_proxy_http, there's a 100 Continue response sent almost straight away by Apache Httpd, which curl does interpret as continue, so it sends the entire request (We are completely uploaded and fine) before it eventually gets the 401 response.

*   Trying 127.0.0.1... connected
* Server auth using Basic with user 'user'
> PUT /myservlet/testfile HTTP/1.1
> Authorization: Basic xxxxxxxxxxxxxxxxx
> User-Agent: curl/7.22.0
> Host: localhost
> Accept: */*
> Content-Length: xxxxxx
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 401 Unauthorized
< Date: xxxxxxxxxxxxxxxx
< Server: Jetty(7.4.5.v20110725)
* Authentication problem. Ignoring this.
< WWW-Authenticate: basic realm="Test Realm"
< Content-Length: 0
< Via: 1.1 localhost
< Content-Type: xxxxxxxxxxxxxx
< 
* Connection #0 to host localhost left intact
* Closing connection #0

Is there a way to prevent mod_proxy_http from using the 100 Continue code and to make it wait for the 401 status code from the backend server before sending its first response?

I've tried to follow the following suggestion from this question, but this didn't solve the problem (it wasn't quite the same problem anyway):

    ProxyPass /myservlet/ http://localhost:8080/myservlet/
    <Location /myservlet/>
            RequestHeader unset Expect early
    </Location>

I'd like to learn how to configure OpenLDAP (2.4), with the objective to deploy it on an Ubuntu 10.04 LTS system. Since slapd.conf usage is deprecated, I'm trying to understand better how to use the cn=config format. Unfortunately, I find the cn=config model quite confusing.

What I'm specifically concerned about is the ability to comment (plain English) and group options, as well as comment out options that I'm trying out.

I've already managed to set up some OpenLDAP options successfully (e.g. SSL/TLS usage), but I've initially relied on slaptest -f ... -F ... to do the conversion. This is fine, but what I find hard to figure out is which part of the initial slapd.conf file produces which part of the cn=config directory, and what matters when combining various options in the final configuration.

The other related problem is the ability to revert a wrongly configured option by commenting it out. Maybe it's a bad habit, but I find it convenient to have the ability to try out an option and then disable it if it wasn't quite right. Experimenting with slaptest is fine for small individual tests, but I'm concerned about the ability to roll back and alter the configuration once it's made it into the live cn=config.

For example, even on a production server, if I get a config option (e.g. Alias entry) in Apache Httpd wrong, I can quickly go back into the configuration file, edit it, reload, and the overall existing configuration doesn't fall apart. So far, I've found that digging back into cn=config to fix something was somewhat more tedious. This is particularly relevant if I need to tweak ACLs, not necessarily after mistakes, but because some of the requirements will have changed.

How should OpenLDAP options (using cn=config) be organized/commented so as to be human-understandable (equivalent to plain comments) and what are the usual methods of reverting incorrect attempts (equivalent to commenting out)?