3👍
wrt/ the X-Requested-With => HTTP_X_REQUESTED_WITH stuff, it’s in conformance with the CGI specifications. Since FastCGI, SCGI and WSGI are all based on the CGI specs, Django developpers choosed to stick to this convention (FWIW, the ModPythonRequest class do the same rewrite for consistency).
So it seems that your problem is that something in the cherokee/scgi chain doesn’t rewrite the headers correctly. Which scgi implemetation are you using ?
2👍
I’m currently working around the issue with a tiny bit of MiddleWare that essentially looks for the “wrong” header and if it exists, appends a new header of the same value:
if 'X-Requested-With' in request.META:
request.META['HTTP_X_REQUESTED_WITH'] = request.META['X-Requested-With']
But I really wish I knew what was supposed to happen with these headers because X-Requested-With
is always sent… I don’t see why that should be translated in to HTTP_X_REQUESTED_WITH
and why it’s not.
Edit: The cause appears to be deep within the actual web server.
case 'X':
if (header_equals ("X-Forwarded-For", header_x_forwarded_for, begin, header_len)) {
ret = add_known_header (hdr, header_x_forwarded_for, val_offs, val_len);
} else if (header_equals ("X-Forwarded-Host", header_x_forwarded_host, begin, header_len)) {
ret = add_known_header (hdr, header_x_forwarded_host, val_offs, val_len);
} else
goto unknown;
break;
I’ve filed a bug to get my header added but should all X-* headers be converted into HTTP_X_* headers?