Wrong status code #789

mloureiro · 2014-08-26T11:34:21Z

I'm using Guzzle to test eZ Publish REST server, in which has a request:

DELETE /ezp/api/v2/content/typegroups/<ID>

That should return a 404 when not found, but (from the tested clients) only Guzzle returns a 200.

Firefox RESTClient addon

    Status Code:        404 Not Found
    Cache-Control:      private
    Connection:         Keep-Alive
    Content-Type:       application/vnd.ez.api.ErrorMessage+xml
    Date:               Tue, 26 Aug 2014 10:44:37 GMT
    Keep-Alive:         timeout=5, max=100
    Server:             Apache/2.2.22 (Debian)
    Transfer-Encoding:  chunked
    X-Powered-By:       PHP/5.4.4-14+deb7u12

Buzz

  Scenario: Get a informative error when deleting a non existent Content Type Group # vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishRestBundle/Features/ContentTypeGroup/delete.feature:13
    Given I have "administrator" permissions                                        # eZ\Bundle\EzPublishRestBundle\Features\Context\SubContext\Authentication::iAmLoggedInAsAn()
    And there isn't a Content Type Group with id "{id}"                             # EzSystems\BehatBundle\ObjectContext\ContentTypeGroup::iDontHaveContentTypeGroupWithId()
    When I send a "DELETE" request to "/content/typegroups/{id}"                    # eZ\Bundle\EzPublishRestBundle\Features\Context\RestContext::iCreateAndSendRequest()
    Then I see a not found exception                                                # eZ\Bundle\EzPublishRestBundle\Features\Context\SubContext\Exception::iSeeNotFoundError()

1 scenario (1 passed)
4 steps (4 passed)

Guzzle 3 and Guzzle 4:

  Scenario: Get a informative error when deleting a non existent Content Type Group # vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishRestBundle/Features/ContentTypeGroup/delete.feature:13
    Given I have "administrator" permissions                                        # eZ\Bundle\EzPublishRestBundle\Features\Context\SubContext\Authentication::iAmLoggedInAsAn()
    And there isn't a Content Type Group with id "{id}"                             # EzSystems\BehatBundle\ObjectContext\ContentTypeGroup::iDontHaveContentTypeGroupWithId()
    When I send a "DELETE" request to "/content/typegroups/{id}"                    # eZ\Bundle\EzPublishRestBundle\Features\Context\RestContext::iCreateAndSendRequest()
    Then I see a not found exception                                                # eZ\Bundle\EzPublishRestBundle\Features\Context\SubContext\Exception::iSeeNotFoundError()
      Expected status code '404' found '200'
      Failed asserting that '200' matches expected '404'.

1 scenario (1 failed)
4 steps (3 passed, 1 failed)

Guzzle4 request print_r

Guzzle4 response print_r

GuzzleHttp\Message\Response Object
(
    [reasonPhrase:GuzzleHttp\Message\Response:private] => OK
    [statusCode:GuzzleHttp\Message\Response:private] => 200
    [effectiveUrl:GuzzleHttp\Message\Response:private] => http://behat.deb/api/ezp/v2/content/typegroups/351
    [headers:GuzzleHttp\Message\AbstractMessage:private] => Array
        (
            [date] => Array
                (
                    [0] => Tue, 26 Aug 2014 10:50:09 GMT
                )

            [server] => Array
                (
                    [0] => Apache/2.2.22 (Debian)
                )

            [x-powered-by] => Array
                (
                    [0] => PHP/5.4.4-14+deb7u12
                )

            [vary] => Array
                (
                    [0] => Accept-Encoding
                )

            [content-length] => Array
                (
                    [0] => 5334
                )

            [content-type] => Array
                (
                    [0] => text/html
                )

        )

    [headerNames:GuzzleHttp\Message\AbstractMessage:private] => Array
        (
            [date] => Date
            [server] => Server
            [x-powered-by] => X-Powered-By
            [vary] => Vary
            [content-length] => Content-Length
            [content-type] => Content-Type
        )

    [body:GuzzleHttp\Message\AbstractMessage:private] => GuzzleHttp\Stream\Stream Object
        (
            [stream:GuzzleHttp\Stream\Stream:private] => Resource id #809
            [size:GuzzleHttp\Stream\Stream:private] => 
            [seekable:GuzzleHttp\Stream\Stream:private] => 1
            [readable:GuzzleHttp\Stream\Stream:private] => 1
            [writable:GuzzleHttp\Stream\Stream:private] => 1
            [uri:GuzzleHttp\Stream\Stream:private] => php://temp
        )

    [protocolVersion:GuzzleHttp\Message\AbstractMessage:private] => 1.1
)

eZ Publish issue: https://jira.ez.no/browse/EZP-23285

The text was updated successfully, but these errors were encountered:

mtdowling · 2014-08-26T15:14:20Z

Are there event listeners in your testing environment that could be causing this? Can you provide debug output (verbose curl output) so we can see what's actually sent over the wire?

You can turn on debug output with the following:

$client->setDefaultOption('debug', true);

mloureiro · 2014-08-27T13:19:58Z

about the events I would say no, maybe @andrerom could help us here.

So the output is:

 Scenario: Get a informative error when deleting a non existent Content Type Group
    Given I have "administrator" permissions
    And there isn't a Content Type Group with id "{id}"
* About to connect() to localhost port 80 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 80 (#0)
* 0x170ac00 is at send pipe head!
* STATE: CONNECT => DO handle 0x170a8d0; (connection #0) 
> DELETE /api/ezp/v2/content/typegroups/540 HTTP/1.1
Host: localhost
User-Agent: Guzzle/3.9.2 curl/7.26.0 PHP/5.4.4-14+deb7u12
Authorization: Basic YWRtaW46cHVibGlzaA==
Content-Length: 0

* STATE: DO => DO_DONE handle 0x170a8d0; (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0x170a8d0; (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0x170a8d0; (connection #0) 
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Wed, 27 Aug 2014 13:17:38 GMT
< Server: Apache/2.2.22 (Debian)
< X-Powered-By: PHP/5.4.4-14+deb7u12
< Vary: Accept-Encoding
< Content-Length: 5332
< Content-Type: text/html
< 
* STATE: PERFORM => DONE handle 0x170a8d0; (connection #0) 
* Connection #0 to host localhost left intact
* Expire cleared
    When I send a "DELETE" request to "/content/typegroups/{id}"
    Then I see a not found exception
      Expected status code '404' found '200'
      Failed asserting that 200 matches expected '404'.

1 scenario (1 failed)
4 steps (3 passed, 1 failed)
0m0.318s

mtdowling · 2014-08-27T15:52:39Z

The server returned a 200, so it looks like Guzzle is doing the right thing. Maybe there's an issue with the test itself?

On Aug 27, 2014, at 6:19 AM, Marcos Loureiro notifications@github.com wrote:

about the events I'm not sure maybe @andrerom could help us here.
But I would say no.

So the output is:

Scenario: Get a informative error when deleting a non existent Content Type Group
Given I have "administrator" permissions
And there isn't a Content Type Group with id "{id}"

About to connect() to localhost port 80 (#0)

Trying ::1...

connected

Connected to localhost (::1) port 80 (#0)

0x170ac00 is at send pipe head!

STATE: CONNECT => DO handle 0x170a8d0; (connection #0)

DELETE /api/ezp/v2/content/typegroups/540 HTTP/1.1
Host: localhost
User-Agent: Guzzle/3.9.2 curl/7.26.0 PHP/5.4.4-14+deb7u12
Authorization: Basic YWRtaW46cHVibGlzaA==
Content-Length: 0

STATE: DO => DO_DONE handle 0x170a8d0; (connection #0)

STATE: DO_DONE => WAITPERFORM handle 0x170a8d0; (connection #0)

STATE: WAITPERFORM => PERFORM handle 0x170a8d0; (connection #0)

additional stuff not fine transfer.c:1037: 0 0

additional stuff not fine transfer.c:1037: 0 0

HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Wed, 27 Aug 2014 13:17:38 GMT
< Server: Apache/2.2.22 (Debian)
< X-Powered-By: PHP/5.4.4-14+deb7u12
< Vary: Accept-Encoding
< Content-Length: 5332
< Content-Type: text/html
<

STATE: PERFORM => DONE handle 0x170a8d0; (connection #0)

Connection #0 to host localhost left intact

Expire cleared
When I send a "DELETE" request to "/content/typegroups/{id}"
Then I see a not found exception
Expected status code '404' found '200'
Failed asserting that 200 matches expected '404'.

1 scenario (1 failed)
4 steps (3 passed, 1 failed)
0m0.318s
—
Reply to this email directly or view it on GitHub.

mloureiro · 2014-08-27T16:06:57Z

looking at Guzzle request print_r

It looks that the request is done as:
Method: DELETE
host: http://behat.deb
path: /api/ezp/v2/content/typegroups/351

and using cURL directly form cli as:
curl -X DELETE -u admin:publish --url http://behat.deb/api/ezp/v2/content/typegroups/351 -v

ツ /var/www/html/behat/vendor/ezsystems/ezpublish-kernel (master) » curl -X DELETE -u admin:publish --url http://behat.deb/api/ezp/v2/content/typegroups/351 -v
* About to connect() to behat.deb port 80 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to behat.deb (127.0.0.1) port 80 (#0)
* Server auth using Basic with user 'admin'
> DELETE /api/ezp/v2/content/typegroups/351 HTTP/1.1
> Authorization: Basic YWRtaW46cHVibGlzaA==
> User-Agent: curl/7.26.0
> Host: behat.deb
> Accept: */*
> 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not Found
< Date: Wed, 27 Aug 2014 16:04:41 GMT
< Server: Apache/2.2.22 (Debian)
< X-Powered-By: PHP/5.4.4-14+deb7u12
< Cache-Control: private
< Transfer-Encoding: chunked
< Content-Type: application/vnd.ez.api.ErrorMessage+xml
< 
<?xml version="1.0" encoding="UTF-8"?>
<ErrorMessage media-type="application/vnd.ez.api.ErrorMessage+xml"><errorCode>404</errorCode><errorMessage>Not Found</errorMessage><errorDescription>Could not find 'eZ\Publish\SPI\Persistence\Content\Type\Group' with identifier 'ID: 351'</errorDescription><trace>#0 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Type/MemoryCachingHandler.php(106): eZ\Publish\Core\Persistence\Legacy\Content\Type\Handler-&gt;loadGroup('351')
#1 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Cache/ContentTypeHandler.php(78): eZ\Publish\Core\Persistence\Legacy\Content\Type\MemoryCachingHandler-&gt;loadGroup('351')
#2 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Repository/ContentTypeService.php(193): eZ\Publish\Core\Persistence\Cache\ContentTypeHandler-&gt;loadGroup('351')
#3 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/SignalSlot/ContentTypeService.php(108): eZ\Publish\Core\Repository\ContentTypeService-&gt;loadContentTypeGroup('351')
#4 /var/www/html/behat/ezpublish/cache/prod/ezpublishProdProjectContainer.php(13940): eZ\Publish\Core\SignalSlot\ContentTypeService-&gt;loadContentTypeGroup('351')
#5 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/REST/Server/Controller/ContentType.php(143): eZPublishCoreRepositoryContentTypeService_0000000060d5e97800000000f9509051-&gt;loadContentTypeGroup('351')
#6 [internal function]: eZ\Publish\Core\REST\Server\Controller\ContentType-&gt;deleteContentTypeGroup('351')
#7 /var/www/html/behat/ezpublish/bootstrap.php.cache(2872): call_user_func_array(Array, Array)
#8 /var/www/html/behat/ezpublish/bootstrap.php.cache(2846): Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#9 /var/www/html/behat/ezpublish/bootstrap.php.cache(2975): Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/html/behat/ezpublish/bootstrap.php.cache(2255): Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel-&gt;handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/Kernel.php(67): Symfony\Component\HttpKernel\Kernel-&gt;handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(466): eZ\Bundle\EzPublishCoreBundle\Kernel-&gt;handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/HttpCache/HttpCache.php(60): Symfony\Component\HttpKernel\HttpCache\HttpCache-&gt;forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#14 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(243): Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache-&gt;forward(Object(Symfony\Component\HttpFoundation\Request), true)
#15 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(260): Symfony\Component\HttpKernel\HttpCache\HttpCache-&gt;pass(Object(Symfony\Component\HttpFoundation\Request), true)
#16 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/HttpCache.php(57): Symfony\Component\HttpKernel\HttpCache\HttpCache-&gt;invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
#17 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(189): eZ\Bundle\EzPublishCoreBundle\HttpCache-&gt;invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
#18 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/HttpCache.php(36): Symfony\Component\HttpKernel\HttpCache\HttpCache-&gt;handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/www/html/behat/web/index.php(77): eZ\Bundle\EzPublishCoreBundle\HttpCache-&gt;handle(Object(Symfony\Component\HttpFoundation\Request))
#20 {main}</trace><file>/var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Type/Handler.php</file><line>128</line></ErrorMessage>
* Connection #0 to host behat.deb left intact
* Closing connection #0

mtdowling · 2014-08-27T17:05:40Z

I think I missed what you're trying to show me. Can you tell me where you think guzzle is doing the wrong thing? It still looks like there's something else wrong based on the curl output that you got when using guzzle.

I would bet if you created a one-off script to contact your test server that it would work without issue. If that's the case, then something else is wrong.

On Aug 27, 2014, at 9:06 AM, Marcos Loureiro notifications@github.com wrote:

looking at Guzzle request print_r

It looks that the request is done as:
Method: DELETE
host: http://behat.deb
path: /api/ezp/v2/content/typegroups/351

and using cURL directly form cli as:
curl -X DELETE -u admin:publish --url http://behat.deb/api/ezp/v2/content/typegroups/351 -v

ツ /var/www/html/behat/vendor/ezsystems/ezpublish-kernel (master) » curl -X DELETE -u admin:publish --url http://behat.deb/api/ezp/v2/content/typegroups/351 -v

About to connect() to behat.deb port 80 (#0)

Trying 127.0.0.1...

connected

Connected to behat.deb (127.0.0.1) port 80 (#0)

Server auth using Basic with user 'admin'

DELETE /api/ezp/v2/content/typegroups/351 HTTP/1.1
Authorization: Basic YWRtaW46cHVibGlzaA==
User-Agent: curl/7.26.0
Host: behat.deb
Accept: /

additional stuff not fine transfer.c:1037: 0 0

HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not Found
< Date: Wed, 27 Aug 2014 16:04:41 GMT
< Server: Apache/2.2.22 (Debian)
< X-Powered-By: PHP/5.4.4-14+deb7u12
< Cache-Control: private
< Transfer-Encoding: chunked
< Content-Type: application/vnd.ez.api.ErrorMessage+xml
< 404Not FoundCould not find 'eZ\Publish\SPI\Persistence\Content\Type\Group' with identifier 'ID: 351'#0 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Type/MemoryCachingHandler.php(106): eZ\Publish\Core\Persistence\Legacy\Content\Type\Handler->loadGroup('351')
Rename Client.php when running phing template #1 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Cache/ContentTypeHandler.php(78): eZ\Publish\Core\Persistence\Legacy\Content\Type\MemoryCachingHandler->loadGroup('351')
Add fix for multiple cache control headers #2 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Repository/ContentTypeService.php(193): eZ\Publish\Core\Persistence\Cache\ContentTypeHandler->loadGroup('351')
Create documentation on writing plugins #3 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/SignalSlot/ContentTypeService.php(108): eZ\Publish\Core\Repository\ContentTypeService->loadContentTypeGroup('351')
Create documentation on the caching plugin #4 /var/www/html/behat/ezpublish/cache/prod/ezpublishProdProjectContainer.php(13940): eZ\Publish\Core\SignalSlot\ContentTypeService->loadContentTypeGroup('351')
Bugfix for errored and retried requests #5 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/REST/Server/Controller/ContentType.php(143): eZPublishCoreRepositoryContentTypeService_0000000060d5e97800000000f9509051->loadContentTypeGroup('351')
Move the mock response queue to an HTTP plugin #6 [internal function]: eZ\Publish\Core\REST\Server\Controller\ContentType->deleteContentTypeGroup('351')
Create a pluggable test web server interface #7 /var/www/html/behat/ezpublish/bootstrap.php.cache(2872): call_user_func_array(Array, Array)
Add a history plugin #8 /var/www/html/behat/ezpublish/bootstrap.php.cache(2846): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
Check if cURL is installed #9 /var/www/html/behat/ezpublish/bootstrap.php.cache(2975): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
Raw Data #10 /var/www/html/behat/ezpublish/bootstrap.php.cache(2255): Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
CurlConstants class file missing? #11 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/Kernel.php(67): Symfony\Component\HttpKernel\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
Inconsistent definition of ClientInterface->get() #12 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(466): eZ\Bundle\EzPublishCoreBundle\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
composer.json has missing dependencies #13 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/HttpCache/HttpCache.php(60): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
The '@filename' syntax for uploads has serious security implications #14 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(243): Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
Improve font contrast on website #15 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(260): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
Add support for URI templates #16 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/HttpCache.php(57): Symfony\Component\HttpKernel\HttpCache\HttpCache->invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
Code generation based on service descriptions #17 /var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php(189): eZ\Bundle\EzPublishCoreBundle\HttpCache->invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
Correct documentation about filter #18 /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/HttpCache.php(36): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
Problem with autloading using PHAR on Windows #19 /var/www/html/behat/web/index.php(77): eZ\Bundle\EzPublishCoreBundle\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request))
Problem with nested array as POST fields. #20 {main}/var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Type/Handler.php128

Connection #0 to host behat.deb left intact

Closing connection #0

—
Reply to this email directly or view it on GitHub.

mloureiro · 2014-08-28T07:41:40Z

I would bet if you created a one-off script to contact your test server that it would work without issue. If that's the case, then something else is wrong.

I'm not sure about it, but the request should be returning a 404 and not a 200 (which does happen in my previous cURL cli request)

I would bet if you created a one-off script to contact your test server that it would work without issue. If that's the case, then something else is wrong.

I've done a simple test with guzzle

    public function iSendTheGuzzleTestRequest()
    {
        $client = new \GuzzleHttp\Client();

        $client->setDefaultOption( 'debug', true );

        $request = $client->createRequest(
            "DELETE",
            "http://behat.deb/api/ezp/v2/content/typegroups/351"
        );

        $request->setHeader(
            'Authorization',
            "Basic " . base64_encode( "admin:publish" )
        );

        try
        {
            $response = $client->send( $request );
        }
        catch ( \GuzzleHttp\Exception\RequestException $e )
        {
            $response = $e->getResponse();
        }
    }

And it returned:

* About to connect() to behat.deb port 80 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to behat.deb (127.0.0.1) port 80 (#0)
* 0x2b8f870 is at send pipe head!
* STATE: CONNECT => DO handle 0x2b8ed50; (connection #0) 
> DELETE /api/ezp/v2/content/typegroups/351 HTTP/1.1
Host: behat.deb
User-Agent: Guzzle/4.2.1 curl/7.26.0 PHP/5.4.4-14+deb7u12
Authorization: Basic YWRtaW46cHVibGlzaA==

* STATE: DO => DO_DONE handle 0x2b8ed50; (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0x2b8ed50; (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0x2b8ed50; (connection #0) 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Thu, 28 Aug 2014 07:38:53 GMT
< Server: Apache/2.2.22 (Debian)
< X-Powered-By: PHP/5.4.4-14+deb7u12
< Vary: Accept-Encoding
< Content-Length: 5334
< Content-Type: text/html
< 
* STATE: PERFORM => DONE handle 0x2b8ed50; (connection #0) 
* Connection #0 to host behat.deb left intact
* Expire cleared

However, again, it should return a 404

mtdowling · 2014-08-28T07:56:21Z

I still think something else is going on here. Guzzle is getting back a 200 response from your server, so I don't see a client-side issue here.

mloureiro · 2014-08-28T08:02:49Z

Tbh, I don't know that deep to say where the problem is.

However, the same request is working with Buzz client and also testing the same with Firefox RESTClient

@bdunogier do you have any idea, if the REST server might/could behave differently depending on which client is being used?

bdunogier · 2014-08-28T09:29:53Z

No, the server doesn't behave differently depending on the client. Not on purpose at least :-)

Based on the output of your commands, the 404 is returned by the server, is it not ?

» curl -X DELETE -u admin:publish --url http://behat.deb/api/ezp/v2/content/typegroups/351 -v
...
< HTTP/1.1 404 Not Found

Or am I missing something ? As I see it, the server returns the correct value, and it is correctly interpreted by BuzzClient and other clients, right ? Or am I missing something, @mtdowling ? Maybe something with 404 and delete ? What happens if you run a GET on the same request with Guzzle, @mloureiro ? The server should reply with a 404, but is Guzzle interpreting it as such ?

mloureiro · 2014-08-28T12:01:52Z

Same response.
Doing it by the curl cli it returns the 404, but through Guzzle 200 is returned

mtdowling · 2014-08-29T23:41:54Z

@bdunogier This is a strange issue. Guzzle isn't actually interpreting anything incorrectly, it's using what was returned from the server via cURL. Guzzle is doing the right thing at the HTTP level. If you look at all of the verbose cURL output provided by @mloureiro, you can see that guzzle actually gets back a 200 response from the server.

I don't see a client-side issue here. This makes me think there's something going on server-side that's returning a 200 response when it shouldn't.

Look at this verbose output:

* About to connect() to behat.deb port 80 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to behat.deb (127.0.0.1) port 80 (#0)
* 0x2b8f870 is at send pipe head!
* STATE: CONNECT => DO handle 0x2b8ed50; (connection #0) 
> DELETE /api/ezp/v2/content/typegroups/351 HTTP/1.1
Host: behat.deb
User-Agent: Guzzle/4.2.1 curl/7.26.0 PHP/5.4.4-14+deb7u12
Authorization: Basic YWRtaW46cHVibGlzaA==

* STATE: DO => DO_DONE handle 0x2b8ed50; (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0x2b8ed50; (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0x2b8ed50; (connection #0) 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Thu, 28 Aug 2014 07:38:53 GMT
< Server: Apache/2.2.22 (Debian)
< X-Powered-By: PHP/5.4.4-14+deb7u12
< Vary: Accept-Encoding
< Content-Length: 5334
< Content-Type: text/html
< 
* STATE: PERFORM => DONE handle 0x2b8ed50; (connection #0) 
* Connection #0 to host behat.deb left intact
* Expire cleared

Notice that the response has a content-type of text/html and a content-length of 5334. I have a suspicion that your server is returning an HTML page by mistake. You should try dumping the body of the response and seeing what page it's getting.

mloureiro · 2014-08-30T08:28:41Z

Ok @mtdowling, asap I'll post here the body.

mloureiro · 2014-09-09T14:14:14Z

Ok, actually as @mtdowling said it seems some problem on the server side

The body of the response contains a noon caught exception:

    │ <br />
      │ <font size='1'><table class='xdebug-error xe-uncaught-exception' dir='ltr' border='1' cellspacing='0' cellpadding='1'>
      │ <tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Fatal error: Uncaught exception 'Qafoo\RMF\View\NowViewFoundException' with message 'No view mapping found.' in /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/REST/Server/View/AcceptHeaderVisitorDispatcher.php on line <i>65</i></th></tr>
      │ <tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Qafoo\RMF\View\NowViewFoundException: No view mapping found. in /var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/REST/Server/View/AcceptHeaderVisitorDispatcher.php on line <i>65</i></th></tr>
      │ <tr><th align='left' bgcolor='#e9b96e' colspan='5'>Call Stack</th></tr>
      │ <tr><th align='center' bgcolor='#eeeeec'>#</th><th align='left' bgcolor='#eeeeec'>Time</th><th align='left' bgcolor='#eeeeec'>Memory</th><th align='left' bgcolor='#eeeeec'>Function</th><th align='left' bgcolor='#eeeeec'>Location</th></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>1</td><td bgcolor='#eeeeec' align='center'>0.0000</td><td bgcolor='#eeeeec' align='right'>226976</td><td bgcolor='#eeeeec'>{main}(  )</td><td title='/var/www/html/behat/web/index.php' bgcolor='#eeeeec'>../index.php<b>:</b>0</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>2</td><td bgcolor='#eeeeec' align='center'>0.0025</td><td bgcolor='#eeeeec' align='right'>998688</td><td bgcolor='#eeeeec'>eZ\Bundle\EzPublishCoreBundle\HttpCache->handle(  )</td><td title='/var/www/html/behat/web/index.php' bgcolor='#eeeeec'>../index.php<b>:</b>77</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>3</td><td bgcolor='#eeeeec' align='center'>0.0025</td><td bgcolor='#eeeeec' align='right'>999600</td><td bgcolor='#eeeeec'>Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(  )</td><td title='/var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>36</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>4</td><td bgcolor='#eeeeec' align='center'>0.0029</td><td bgcolor='#eeeeec' align='right'>1012344</td><td bgcolor='#eeeeec'>eZ\Bundle\EzPublishCoreBundle\HttpCache->invalidate(  )</td><td title='/var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>189</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>5</td><td bgcolor='#eeeeec' align='center'>0.0029</td><td bgcolor='#eeeeec' align='right'>1012536</td><td bgcolor='#eeeeec'>Symfony\Component\HttpKernel\HttpCache\HttpCache->invalidate(  )</td><td title='/var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>57</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>6</td><td bgcolor='#eeeeec' align='center'>0.0029</td><td bgcolor='#eeeeec' align='right'>1012800</td><td bgcolor='#eeeeec'>Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(  )</td><td title='/var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>260</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>7</td><td bgcolor='#eeeeec' align='center'>0.0029</td><td bgcolor='#eeeeec' align='right'>1013144</td><td bgcolor='#eeeeec'>Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache->forward(  )</td><td title='/var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>243</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>8</td><td bgcolor='#eeeeec' align='center'>0.0575</td><td bgcolor='#eeeeec' align='right'>13038488</td><td bgcolor='#eeeeec'>Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(  )</td><td title='/var/www/html/behat/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/HttpCache/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>60</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>9</td><td bgcolor='#eeeeec' align='center'>0.0576</td><td bgcolor='#eeeeec' align='right'>13040288</td><td bgcolor='#eeeeec'>eZ\Bundle\EzPublishCoreBundle\Kernel->handle(  )</td><td title='/var/www/html/behat/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php' bgcolor='#eeeeec'>../HttpCache.php<b>:</b>466</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>10</td><td bgcolor='#eeeeec' align='center'>0.0576</td><td bgcolor='#eeeeec' align='right'>13040544</td><td bgcolor='#eeeeec'>Symfony\Component\HttpKernel\Kernel->handle(  )</td><td title='/var/www/html/behat/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishCoreBundle/Kernel.php' bgcolor='#eeeeec'>../Kernel.php<b>:</b>67</td></tr>
      │ <tr><td bgcolor='#eeeeec' align='center'>11</td><td bgcolor='#eeeeec' align='center'>0.0603</td><td bgcolor='#eeeeec' align='right'>13217600</td><td bgcolor='#eeeeec'>Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(  )</td><td title='/var/www/html/behat/ezpublish/bootstrap.php.cache' bgcolor='#eeeeec'>../bootstrap.php.cache<b>:</b>2272</td></tr>
      │ </table></font>

andrerom · 2014-09-09T16:07:23Z

@mloureiro Probably need to compare the request sent to the server here instead of the response, also make sure you update symfony as there has been some fixes regarding header parsing over the last maintenance releases.

mtdowling · 2014-09-10T22:31:14Z

Is it ok to close this issue now, or do you still think there's a client-side problem?

bdunogier · 2014-09-12T08:56:30Z

I'd say it's fine, right @mloureiro ?

mloureiro · 2014-09-12T09:33:57Z

Yep...
Closing it
If more details pop up I'll reopen
Thanks @mtdowling

chrissound · 2018-05-25T16:39:57Z

Might be the following bug: https://bugs.xdebug.org/view.php?id=587

mloureiro closed this as completed Sep 12, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wrong status code #789

Wrong status code #789

mloureiro commented Aug 26, 2014

mtdowling commented Aug 26, 2014

mloureiro commented Aug 27, 2014

mtdowling commented Aug 27, 2014

mloureiro commented Aug 27, 2014

mtdowling commented Aug 27, 2014

mloureiro commented Aug 28, 2014

mtdowling commented Aug 28, 2014

mloureiro commented Aug 28, 2014

bdunogier commented Aug 28, 2014

mloureiro commented Aug 28, 2014

mtdowling commented Aug 29, 2014

mloureiro commented Aug 30, 2014

mloureiro commented Sep 9, 2014

andrerom commented Sep 9, 2014

mtdowling commented Sep 10, 2014

bdunogier commented Sep 12, 2014

mloureiro commented Sep 12, 2014

chrissound commented May 25, 2018

Wrong status code #789

Wrong status code #789

Comments

mloureiro commented Aug 26, 2014

mtdowling commented Aug 26, 2014

mloureiro commented Aug 27, 2014

mtdowling commented Aug 27, 2014

mloureiro commented Aug 27, 2014

mtdowling commented Aug 27, 2014

mloureiro commented Aug 28, 2014

mtdowling commented Aug 28, 2014

mloureiro commented Aug 28, 2014

bdunogier commented Aug 28, 2014

mloureiro commented Aug 28, 2014

mtdowling commented Aug 29, 2014

mloureiro commented Aug 30, 2014

mloureiro commented Sep 9, 2014

andrerom commented Sep 9, 2014

mtdowling commented Sep 10, 2014

bdunogier commented Sep 12, 2014

mloureiro commented Sep 12, 2014

chrissound commented May 25, 2018