Codeception: [REST] Preconfigured Content-Type header changes to application/x-www-form-urlencoded when request data is provided

[evpav]

Suite configuration:

class_name: ApiTester
modules:
    enabled:
        - \Helper\Api
        - REST:
            url: http://localhost/
            depends: PhpBrowser
            part: Json
        - PhpBrowser:
            url: http://localhost/
            headers:
                Accept: application/json
                Content-Type: application/json

test:

$I->sendPOST('user/login');
// on server: $_SERVER["HTTP_CONTENT_TYPE"] === 'application/json'
$I->sendPOST('user/login', ['username' => 'test', 'password' => 'test']);
// on server: $_SERVER["HTTP_CONTENT_TYPE"] === 'application/x-www-form-urlencoded'

Codeception version 2.2.5

Also these preset headers are not showing up in the verbose output:

 I send post "user/login"
  [Request] POST http://localhost/user/login []
  [Request Headers] []

 I send post "user/login",{"username":"test","password":"test"}
  [Request] POST http://localhost/user/login {"username":"test","password":"test"}
  [Request Headers] []

[Naktibalda]

To support your case REST would have to read headers from module configuration in _before

An additional difficulty could be that headers is not a parameter of PhpBrowser - it goes straight to Guzzle.

[evpav]

So they do not behave like the headers set via haveHttpHeader then? But why should they be any different?

[boblgum]

Same issue here.
@Naktibalda i'm not sure you are right.
headers from PhpBrowser are used by REST-module

Before sending a request (sendPOST etc) REST just clears any connection module headers.
See Codeception/Module/REST.php#L99
But while preparing the request the module checks the headers to clarify if it should be json-encoded
See Codeception/Module/REST.php#L472

So the method CodeceptionModuleREST::encodeApplicationJson get called before every request, but will never return json-encoded parameters.

IMHO accessing variables in this way is not a good style how to work with injected dependencies

[igorsantos07]

Any chance this could be tackled? It seems it was possible in previous versions (#2401), but I can confirm the OP's config do not work for me either.

This seems to be a common use-case - afterwards, we should all be expecting JSON payloads on API tests, right? (or SOAP, for what it matters...). I wonder if this got little attention because we're doing it wrong and doc didn't help, or just because usually people just return JSON by default and that's it.

[Naktibalda]

I'm pretty sure that this issue was fixed by #4582

[igorsantos07]

@Naktibalda hmmm indeed, on further investigation I understand better the confusion.

The OP example does work now (but the issue I linked doesn't); however, you need to configure "another module" (PhpBrowser), making this use-case non-transparent. This doesn't sound bad - as long as docs cover it -, but the biggest issue is that, once you open PhpBrowser to config, you MUST re-set the URL. In the end, to set fairly common headers for REST testing, you have to dig into dependency docs and duplicate the URL.

I would suggest to include headers as a REST option as well, or at least allow PhpBrowser to retain the settings it gets from REST (not sure how it works and if that seems feasible). In any case, this should be documented in the REST module as it's a common use-case :)

Sorry if I'm sounding rude; it's definitely not the intention, but after a long week this is the best I could write!

Works but a bit of boilerplate / needs DRY:

suites:
  api:
    modules:
      enabled:
        - REST:
            depends: PhpBrowser
            url: http://0.0.0.0:8000/api
      config:
        PhpBrowser:
          url: http://0.0.0.0:8000/api
          headers:
            Content-Type: application/json

Expected (more natural?):

suites:
  api:
    modules:
      enabled:
        - REST:
            depends: PhpBrowser
            url: http://0.0.0.0:8000/api
            headers:
              Content-Type: application/json

[Naktibalda]

Closing because original issue was fixed in 2017.

[igorsantos07]

This is not exactly closed, although it became more of a docs problem - I guess it wasn't clear enough from my past comment. I'll PR clarifications.