API: Unexpected use of 'Accept' header (as Content-Type)

[pardahlman]

Top of the morning 🌤

I'm running Akeneo 1.7.2, same instance as in #6099.

I'm trying to use the endpoint for creating a media file, which according to the documentation requires two headers:

• Content-type Equal to multipart/form-data, no other value allowed
• Authorization Equal to 'Bearer xxx', xxx being the authentication token

I posted a request with the current headers

POST http://127.0.0.1:8080/api/rest/v1/media-files HTTP/1.1
Connection: Keep-Alive
Content-Type: multipart/form-data
Accept-Encoding: gzip, deflate
Authorization: Bearer OTM4MWQ5NGU4MWY3N2Y3OTJmMDI3ZGY3ZThlZDY5NGMyYmYzNDk0YWE3ODFmYzk0MjZjZDRmN2EzNGU4ZGFmZQ
Content-Length: 5901
Host: 127.0.0.1:8080

And I got the following response from the API

{
  "code": 415,
  "message": "\"multipart\/form-data\" in \"Content-Type\" header is not valid. Only \"application\/json\" is allowed."
}

The message comest from CheckHeadersRequestSubscriber. When digging further into this, the secondary value (retrieved from $best->getValue()) comes originally from this line of code

$best = $this->formatNegotiator->getBest($request->headers->get('accept'));

That retrieves the Accept header. A bit down the file there is a check if the verb is POST and if so it executes this line of code:

$contentType = $request->headers->get('content-type');

That retrieves the Content-type header. These two values are then compared, which, if I'm reading the code right, is not correct.

Worth noting also, when looking at the headers of my original request there is no Accept header present, but still application/json is found as the "best" match.

As a work-around, I added the Accept header to my request

POST http://127.0.0.1:8080/api/rest/v1/media-files HTTP/1.1
Connection: Keep-Alive
Content-Type: multipart/form-data
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Bearer YjVlYzg5YWYwYzQzZTM0MGQwZjZlNTlhYWNiMTA1YjliNTE3M2U0Yjg2OGI2NmNjNGRkNjQ3YmVjZTBlYjMzZg
Content-Length: 5927
Host: 127.0.0.1:8080

And the header check passed.

[ahocquard]

Hello @pardahlman,

It's a well-known bug. Actually, even curl add the Accept header "/" by default... FosRestBundle is not very customisable on that point and it leads to some weird behavior :/

It will be fixed in a patch. Your workaround is the good one.

Thanks for your report !

Alexandre

[pardahlman]

Aloha!

Just want to make sure that I understand what you're saying. Do you mean that the bug in Akeneo PIM's CheckHeadersRequestSubscriber class is well-known and will be fixed? If so, no further questions! 🙂

[ahocquard]

Yes, it will be fix in a 1.7 patch :)

[pardahlman]

Perfecto! I've gotten my answer. You can deside if you want to close this ticket or keep it open for reference!

[mickaelandrieu]

Thank you for your feedback @pardahlman and @ahocquard for the answer.

Except if I'm wrong, the issue is still valid so I let the issue open :)

[ahocquard]

@mickaelandrieu Not fixed yet, I hope it will be soon.

[LaureBrosseau]

Hello @pardahlman, the latest 1.7 version, the 1.7.5 contains the fix for this issue. You can now update your PIM installation. Kind regards,