I wish it was that easy. The Apache headers that you can adjust are not the ones creating the problem. The problem is with the response header size which you cannot adjust. Following is a comment from Graham Dumpleton:
On 17/01/2014, at 5:36 PM, "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" <mark.m.mil...@hp.com<mailto:mark.m.mil...@hp.com>> wrote: Hello Graham, I have run across a response header size limitation that I don’t know how to get around. I am using mod_wsgi with Apache2, SSL, and OpenStack Keystone. The problem I am running into is that the tokens returned by Keystone can be > 8190 bytes in length. When they are greater than 8190 I get the following error: [Thu Jan 16 22:27:47 2014] [info] Initial (No.1) HTTPS request received for child 231 (server d00-50-56-8e-75-82.cloudos.org<http://d00-50-56-8e-75-82.cloudos.org>:5000) [Thu Jan 16 22:27:47 2014] [info] [client 192.168.124.2] mod_wsgi (pid=24676, process='keystone', application='d00-50-56-8e-75-82.cloudos.org<http://d00-50-56-8e-75-82.cloudos.org>:5000|'): Loading WSGI script '/etc/apache2/wsgi/keystone/main'. [Thu Jan 16 22:27:48 2014] [error] [client 192.168.124.2] malformed header from script. Bad header=mVmOTdhMmUzIn0sIHsidXJsIjogImh: main [Thu Jan 16 22:27:48 2014] [debug] mod_deflate.c(615): [client 192.168.124.2] Zlib: Compressed 592 to 377 : URL /v3/auth/tokens [Thu Jan 16 22:27:48 2014] [debug] ssl_engine_kernel.c(1884): OpenSSL: Write: SSL negotiation finished successfully [Thu Jan 16 22:27:48 2014] [info] [client 192.168.124.2] Connection closed to child 231 with standard shutdown (server d00-50-56-8e-75-82.cloudos.org<http://d00-50-56-8e-75-82.cloudos.org>:5000) Is there some way to increase the response header size limit? This is a hardwired limitation within the Apache function used by mod_wsgi to parse the response headers returned from a WSGI application running in daemon mode. if (!(l = strchr(w, ':'))) { if (!buffer) { /* Soak up all the script output - may save an outright kill */ while ((*getsfunc)(w, MAX_STRING_LEN - 1, getsfunc_data) > 0) { continue; } } ap_log_rerror(SCRIPT_LOG_MARK, APLOG_ERR|APLOG_TOCLIENT, 0, r, "malformed header from script '%s': Bad header: %.30s", apr_filepath_name_get(r->filename), w); return HTTP_INTERNAL_SERVER_ERROR; } Besides copying the function from Apache into mod_wsgi and modifying it, which has been on the cards for a while for other reasons, the only thing I can suggest is to used embedded mode, which in general I wouldn't recommend. What is the nature of the token? Graham From: Adam Young [mailto:ayo...@redhat.com] Sent: Monday, February 03, 2014 10:23 AM To: openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] Keystone PKI token too much long On 01/31/2014 11:24 AM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: Hello, We ran into a problem when using Apache2 and WSGi as the web front end for Keystone. Keystone v2.0 returns the token in the response body but v3 returns the token in the response header. Apache has an internal limit of 8190 bytes for the response header which means that you will get an error when you request a token with includes an endpoint catalog that has more than about 12 endpoints in it. We had to turn the catalog off. Setting the header size is a config option; I believe it is LimitRequestFieldSize http://httpd.apache.org/docs/2.2/mod/core.html#LimitRequestFieldSize So set that larger. 10K should be acceptable, based on the reports I've heard. Mark From: Remo Mattei [mailto:r...@italy1.com] Sent: Friday, January 31, 2014 5:41 AM To: Ferreira, Rafael Cc: openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Subject: Re: [Openstack] [Barbican] Keystone PKI token too much long Hi Rafael Do you have the info on how that has been implemented. Thanks Remo Inviato da iPhone () Il giorno Jan 31, 2014, alle ore 8:27, "Ferreira, Rafael" <r...@io.com<mailto:r...@io.com>> ha scritto: By the way, you can achieve the same benefits of uuid tokens (shorter tokens) with PKI by simply using a md5 hash of the PKI token for your X-Auth headers. This is poorly documented but it seems to work just fine. From: Adam Young <ayo...@redhat.com<mailto:ayo...@redhat.com>> Date: Tuesday, January 28, 2014 at 1:41 PM To: "openstack@lists.openstack.org<mailto:openstack@lists.openstack.org>" <openstack@lists.openstack.org<mailto:openstack@lists.openstack.org>> Subject: Re: [Openstack] [Barbican] Keystone PKI token too much long On 01/22/2014 12:21 PM, John Wood wrote: (Adding another member of our team Douglas) Hello Giuseppe, For questions about news or patches for Keystone's PKI vs UUID modes, you might reach out to the openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org> mailing list, with the subject line prefixed with [openstack-dev] [keystone] Our observation has been that the PKI mode can generate large text blocks for tokens (esp. for large service catalogs) that cause http header errors. Regarding the specific barbican scripts you are running, we haven't run those in a while, so I'll investigate as we might need to update them. Please email back your /etc/barbican/barbican-api-paste.ini paste config file when you have a chance as well. Thanks, John ________________________________ From: Giuseppe Galeota [giuseppegale...@gmail.com<mailto:giuseppegale...@gmail.com>] Sent: Wednesday, January 22, 2014 7:36 AM To: openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Cc: John Wood Subject: [Openstack] [Barbican] Keystone PKI token too much long Dear all, I have configured Keystone for Barbican using this guide<https://github.com/cloudkeep/barbican/wiki/Developer-Guide-for-Keystone>. Is there any news or patch about the need to use a shorter token? I would not use a modified token. Its a known problem. You can request a token without the service catalog using an extension. One possible future enhancement is to compress the key. Following you can find an extract of the linked guide:  (Optional) Typical keystone setup creates PKI tokens that are long, do not fit easily into curl requests without splitting into components. For testing purposes suggest updating the keystone database with a shorter token-id. (An alternative is to set up keystone to generate uuid tokens.) From the above output grad the token expiry value, referred to as "x-y-z" mysql -u rootuse keystone;update token set id="foo" where expires="x-y-z" ; Thank you, Giuseppe _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack The communication contained in this e-mail is confidential and is intended only for the named recipient(s) and may contain information that is privileged, proprietary, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Please immediately notify the sender of the error, and delete this communication including any attached files from your system. Thank you for your cooperation. !DSPAM:1,52eba57b226891577754402! _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack !DSPAM:1,52eba57b226891577754402! _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
