Fixes #23, thanks to @garoevans for reporting the issue, and fixing soon...

[harikt]

...er than later

[pmjones]

Good catch, and a good start. It needs to also check CONTENT_LENGTH and CONTENT_MD5.

[harikt]

@pmjones done. Have a look.

[pmjones]

Argh -- I think this is in the wrong place.

First off, look at https://tools.ietf.org/rfc/rfc3875.txt -- this is what PHP follows. There are no such keys as HTTP_(CONTENT_TYPE|CONTENT_LENGTH) so checking for HTTP_* versions of them makes no sense. I was wrong to mention CONTENT_MD5 as it's not listed there, so that would be HTTP_CONTENT_MD5 (I guess).

The issue appears to be in the "headers" class, not the "content" class. The loop there looks only for HTTP_* headers and does not track the CONTENT_* headers.

Sorry for the back-and-forth, man. :-/

[pmjones]

Here's another note about it: http://php.net/manual/en/reserved.variables.server.php#110763

[pmjones]

@harikt I think this will do the trick: bba1e67

Let me know if you think something else has to happen.

[harikt]

I am running with php version 5.4, not sure your php version.

The php's built in server when you have a Content-Type: application/json will not give any result for your query $request->content->getType(); for $_SERVER is having HTTP_CONTENT_TYPE and not CONTENT_TYPE . If you check with apache, then you are right.

I do believe that is true for CONTENT_MD5 .

This is my code

<?php
require __DIR__ . '/vendor/autoload.php';
use Aura\Web\WebFactory;
$web_factory = new WebFactory($GLOBALS);
$request = $web_factory->newRequest();
echo "Hello :) " . $request->content->getType();

echo "<br />\n";

echo isset($_SERVER['CONTENT_TYPE']) ? $_SERVER['CONTENT_TYPE'] : ' none ';

echo "<br />\n";

echo isset($_SERVER['HTTP_CONTENT_TYPE']) ? $_SERVER['HTTP_CONTENT_TYPE'] : ' http none';

echo "<br />\n";

echo isset($_SERVER['CONTENT_MD5']) ? $_SERVER['CONTENT_MD5'] : ' none md5';

echo "<br />\n";

When you use curl -H "Content-Type: application/json" http://localhost:8000 what is the result you are getting?

If it is

Hello :) <br />
 none <br />
application/json<br />
 none md5<br />
 http none md5

then we have not fixed.

Thanks

[pmjones]

The php's built in server when you have a Content-Type: application/json will not give any result for your query $request->content->getType(); for $_SERVER is having HTTP_CONTENT_TYPE and not CONTENT_TYPE . If you check with apache, then you are right.

I wonder if that's a bug in the PHP 5.4 server; the RFC states it should be CONTENT_TYPE and not HTTP_CONTENT_TYPE. Maybe we do need to make an allowance there, as you noted earlier.

[pmjones]

Yes, I'm seeing the behavior you described. I'm on PHP 5.4.22 -- you?

[harikt]

Yes I am in PHP 5.4.22 .

[pmjones]

/me nods

I ask because I went to report the bug, but they won't take bugs on anything other than the latest versions (5.4.24 in this case). I don't have the time to upgrade any time soon -- do you?

[harikt]

Sorry I too don't think so :( .

As this is built in server may be a note is good?.

[pmjones]

/me nods again

OK, so I'll merge this change too, and that at least will make an allowance for the bug. Thanks man!

[jelofson]

I can confirm that php 5.5.3's built in web server does use HTTP_CONTENT_TYPE instead of CONTENT_TYPE.

I just did a var_dump of $_SERVER with curl -H "Content-Type: application/json" http://localhost:8000, but without Aura.Web.

[harikt]

Thank you @jelofson .

[garoevans]

Are you going to attempt to check for 'HTTP_CONTENT_TYPE' just for the use case, or not worth it?

I'm only using the built in server for quick local setup purpose, but have the following in the top of my define.php:

// TODO: remove little hack once https://github.com/auraphp/Aura.Web/issues/23 is resolved
$_SERVER['CONTENT_TYPE'] = $_SERVER['HTTP_CONTENT_TYPE'];

Maybe I should just take the 5 mins to setup a vhost for it on apache :)

[harikt]

@garoevans as @pmjones mentioned the fix is only for built in server, but not sure whether it is worth. ( Reason explained by Paul )

[pmjones]

This appears to be an issue with the PHP web server, not with Aura.Web per se. I have reported it to the PHP folks at https://bugs.php.net/bug.php?id=66606. I don't think it's worthwhile yet to "fix" this in Aura.Web just yet, but we can revisit that assessment later if we need to.

[harikt]

Thanks Paul .

[harikt]

I cleaned my branches again. That is why the branch got lost. Sorry.