Forcing HTTP/1.0 Apache response when PHP is there…

by regilero

29 08 2008
forcing-http10-apache-response-when-php-is-there

Recently I had to force an HTTP/1.0 response with Apache because of a bad Java Parser.

This parser/browser was asking for HTTP/1.1 responses but did’nt understood chunked content encoding. And so giving me a nice Sax exception “content not allowed in prolog”. So, well, I won’t fix this #$*%! code. Better trying to talk to this special User Agent in HTTP/1.0, he might handle it in a better way. Here’s what a chunked content looks like. See the 306c hexa lenght code before the body of the response?

HTTP/1.1 207 Multi-Status
(... lot of headers, but no lenght one ...)
Content-Type: text/xml; charset="utf-8"

306c
<?xml version="1.0" encoding="utf-8"?>
(... here the content ...)

So I have the user agent of this Java HTTP Client, let’s call it ‘NoobieJavaParser’.

I simply wrote in my apache virtualhost config file:

BrowserMatch "^NoobieJavaParser" nokeepalive force-response-1.0 downgrade-1.0

And it should be sufficient. In fact it’s not because of a very old PHP bug (saw first bug report in 2004).

PHP is building is $_SERVER variable by reading Apache env, and PHP doesn’t want any dot in this parsed content. The ‘downgrade-1.0‘ env name seem malicious for PHP. So the env setting looks like that in PHP:

echo $_SERVER['downgrade-1_0'];
-> 1

See the dots is now a ‘_’. It should not hurt anyone, except PHP changed this env name in Apache as well. So when apache is sending the response, he does not care anymore about this downgrade-1_0 settings.

If you want Apache to have the real behaviour, i.e: sending HTTP/1.0 responses for this ‘NoobieJavaParser’ User Agent you must re-set the env of Apache in PHP, with something like that:

if ($_SERVER['downgrade-1_0']){
        apache_setenv(’downgrade-1.0′,’true’);
}
if ($_SERVER['force-response-1_0']){
        apache_setenv(’force-response-1.0′,’true’);
}

Ugly, but it’s PHP’s fault. and no more chunked content after that. And the nice thing is that apache_setenv is not changing $_SERVER, so PHP still does not have this malicious dot.



Some basic things about Apache VirtualHosts

by pounard

29 08 2008

For people who thinks that setup an Apache is easy (and of course, with some experience behind me, I agree), I say, beware of some details.
For those who need real technical documentation on Apache, this is not for you, this article intends to help people who only tries to setup small development or personal web servers (this do not applies on complex environments or needs).

Yesterday, I had to setup a development environment for a colleague, and it took some hours just because of theses:

read more



Nouveau produit d’import/export CSV pour Archetypes

by ebr

12 08 2008

Makina Corpus a réalisé un produit d’import/export CSV Plone 3 pour tous les types de contenus Archetypes.

Plus d’information ici.



Migration d’un site SPIP vers Drupal 1/3

by Pierre

11 08 2008
J'ai eu dans le cadre de mon travail la refonte d'un site contenant un grand volume de donnée. Le coeur de cette refonte reposait sur la migration du site d'une technologie vers une autre. La technologique d'origine est le CMS SPIP, celle d'arrivée le CMS Drupal. read more


Ubuntu Global Bug Jam à Toulouse

by Christophe

5 08 2008

Vu que le WE prochain (du 8 au 10 Aout 2008) a lieu partout dans le monde, le 1er Ubuntu Global bug jam je me lance pour proposer d'en organiser 1 à toulouse... Ben oui je tente de montrer l'exemple ;)

Et déjà c'est quoi un Global Bug Jam ? C'est l'occasion pour un groupe de personnes de se regrouper dans la joie et la bonne humeur pour corriger des bugs Ubuntu... Bien sur les bugs abordés seront simples (une catégorie spéciale doit etre proposée...) histoire de permettre à tout le monde de participer à améliorer la future version Intrepid Ibex. Et puis c'est quand même plus sympa de faire ça en vrai dans la même pièce, plutot que tous derrière un PC dans la même ville...

Je propose donc d'organiser ça Vendredi 8 Aout vers 20h30... Donc surtout si vous êtes intéressés pour y participer merci de laisser un commentaire ici.. Pour le moment il ne manque que des participants ET un endroit pour le faire... Bref si vous avez des idées...



back in loggerhead adventures

by kiorky

5 08 2008

Testing the 'serve-branches' script, as mwh asked me on the previous bug report, i have now something pretty cool :)

So, something nice is that i have dropped away the ugly patch.

see : http://bzr.cryptelium.net in action.

 

What's next?

Michael Hudson, the main developper, told me that the idea is to drop away the loggerhead.conf and to use serve-branches as the main thing to use.

That's a good idea. Usage is simple, nothing to worry about configuration, it just does publishing after all.

 

Little bits i can see as improvments (always reported/planned):

  • a breadcrumb in repo view to browse back
  • Maybe some sort of ajaxified navigator to have the whole tree from the homepage


Minitage Week end work

by kiorky

4 08 2008

What i had done on minitage this week end:

 

Minitage.paste

  • Improved varnish configuration
  • A new plone profile to be directly mapped to a zeo instance

 

Minitage.recipe

  • Pyc are now just regenerated when eggs are moved into the cache. Thanks to Jim Fulton and the appropriate zc.buildout's function i have borrowed :p
  • easy_install method was refactored a bit.
  • eggs install method code is now rock solid until the next bug.

 

 

Thoughts

  • For a long time, i think to cache authenticated content though a http proxy-cache. This can be done with the coordination of the plone cachesetup product and varnish. This will be certainly a next improvment to the varnish template. As i will study a cache solution, next week, in my daly work, it will be normally quickly updated :)

 



loggerhead and auto publishing

by kiorky

3 08 2008

Althought i was playing in the wonderfull world of mercurial, i 'm trying out bazaar and its tools.

The goal of the week end was to set up some repositories and a source browser on top of them.

In bazaar world, there is not much choice to achieve that. In other terms, you re really encouraged to use loggerhead.

 

So, i began to set up a repository, file access and so on... Then look at the loggerhead documentation. Great, there is some sort of auto publishing feature.

This is a mechanism like our beloved mercurial's hgwebdir.cgi to autopublish branches inside a top level directory.

 

Installation

So, the procedure i used was really simple:

Grab it

bzr branch http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/ loggerhead.dev

Edit and point to my top level directory

cp loggerhead.conf* loggerhead.conf

vi loggerhead.conf 

Set up a gentoo init script to start it and schedule for starting after apache2

$ cat /etc/init.d/loggerhead
#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

depend() {
        need net apache2
}

start() {
        ebegin "Starting $server_name server"
        start-stop-daemon --start  --user $user  --quiet --background \
        -p $pid_file -m  --exec "$py"  --  "$start_cmd"
        eend $?
}

stop() {
        ebegin "Stopping $server_name  server"
        "$py"  --  "$stop_cmd"  2>&1 >> /dev/null
        eend $?
}

$ cat /etc/conf.d/loggerhead 
start_cmd=/path/loggerhead.dev/start-loggerhead
stop_cmd=/path/loggerhead.dev/stop-loggerhead
pid_file="/path/loggerhead.dev/loggerhead.pid"
user="apache"
py=`which python`
server_name="Loggerhead"

 Configure apache for serving both bazaar and loggerhead on the same vhost

...
Vhost basic and directories directives
...
# setting an alias to point to the bazaar directory

Alias /repos/ /path/repos/


RewriteEngine on

# mapping to /repos  if we are not browsing on loggerhead or if we are directly "branching"
RewriteCond  %{REQUEST_URI}  !^(/repos/.*)$
RewriteCond  %{REQUEST_URI}  ^(.*\.bzr.*)$
RewriteRule  ^/(.*)$         /repos/$1   [R,L]

# mapping to loggerhead otherwise
RewriteCond  %{REQUEST_URI}  !^(.*\.bzr.*)$
RewriteCond  %{REQUEST_URI}  !^(/repos/.*)$
RewriteCond  %{REQUEST_URI}  !^(/icons/.*)$
RewriteRule  ^/(.*)          http://bzr.cryptelium.net:1337/$1 [P]
RewriteCond  %{REQUEST_URI}  !^(.*\.bzr.*)$
RewriteCond  %{REQUEST_URI}  !^(/repos/.*)$
RewriteCond  %{REQUEST_URI}  !^(/icons/.*)$
RewriteRule  ^/(.*)/$        http://bzr.cryptelium.net:1337/$1 [P]

# The two [P] RewriteRules are just ProxyPass rules which allow to redirect to the loggerhead server.

 

Are we done yet ?

Unfortunatly not.

Loggerhead is stupid and will not publish two branches with same name.

Another thing is that it will take the branch name for display in UI.

I REALLLY do not like that. I prefer to see full pathes in the UI. That helps my little brain with tree view focus to function properly.

 

Why ?

This cannot be served (just b/c will be):

a/c
b/c

 

b/c/d

Results in

d

 

Fix ?

For my own use, i make my own fix :)

But i upstreamed the result there:https://bugs.launchpad.net/loggerhead/+bug/254411

This allows me to publish my repositories with path views :)

 

Result

http://bzr.cryptelium.net/

 



Blog opening

by kiorky

3 08 2008

There is a long time i must have done that.

IT s done now, my blog is open :)

Stay tuned for new entries.

 

What will may be next:

  • Plone customization
  • Refactor logo and design of this bare plone.
  • Integration with cryptelium services
  • Cofee and tea