0

We encountered this problem with different versions of OS & Subversion on the server side, the following details being the same:

  • We used https protocol to access the SVN repositories.
  • We used Apache HTTPD + mod_dav_svn + mod_authz_svn. We also used either mod_auth_kerb or mod_auth_gssapi.
  • The users authenticated with Windows Integrated Authentication. Members of a certain group were allowed to access the SVN repos.
  • The clients were Windows workstations, with fairly recent SVN versions (1.13-1.14).

Some clients worked OK, others got a HTTP 400 Bad Request error on accessing the SVN repository. On the server side the error manifested in a "NO AUTH DATA Client did not send any authentication headers" message in the SSL error log.

Some users consistently succeeded, others consistently failed to access the SVN repos.

Attila Csipak
  • 123
  • 1
  • 9

1 Answers1

0

It turned out that difference between the successful and failing users was the number of the LDAP groups they were members of. The failed users were members of more groups.

It looks like at some point all of these group names are sent from the client to the server in HTTP request headers... which have a size limit.

The solution was to raise the HTTP request header field size with the following directive:

LimitRequestFieldSize 12392

Have a look at the official Apache HTTPD documentation of this directive:

The LimitRequestFieldSize directive allows the server administrator to set the limit on the allowed size of an HTTP request header field. A server needs this value to be large enough to hold any one header field from a normal client request. The size of a normal request header field will vary greatly among different client implementations, often depending upon the extent to which a user has configured their browser to support detailed content negotiation. SPNEGO authentication headers can be up to 12392 bytes.

EDIT: it turns out that 12392 bytes are not necessarily enough for everything, so we raised the limit to 65536. Just to be sure.

Attila Csipak
  • 123
  • 1
  • 9