Support

Akeeba Backup for Joomla!

#36444 Wrong check for header name case sentitive in cloudfiles connector

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by on Wednesday, 16 February 2022 20:17 CST

kessenza

Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!


EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.


Description of my issue:

I found an error in this file administrator/components/com_akeeba/BackupEngine/Postproc/Connector/Cloudfiles/Request.php where you look for case sentitive header Content-Type but often (like in my case) server return header all lower case and they are compliant with HTTP protocol, specifically with message headers specification:

4.2 Message Headers

HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

What happens is that 

Content-Type is not found and then response body json in not decoded 
if (
($this->response->error === false)
&& isset($this->response->headers['Content-Type'])
&& (strstr($this->response->headers['Content-Type'], 'application/json') !== false)
&& isset($this->response->body)
)
{
$this->response->body = json_decode($this->response->body);
}

so Token is not found and applied to PUT request to swift (in my case).

You should correct the code and use case insensitive pattern here

nicholas
Akeeba Staff
Manager

We will change that but I do have a question. Are you using RackSpace CloudFiles proper or a third party provider? If you are using RackSpace CloudFiles, which region are you using? The header check case sensitivity was the result of observing what RackSpace returned, it wasn't arbitrary.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

kessenza

I am using an Italian provider that has an European cloud based on openstack. It worked perfectly until last month. I supposed they updated keystone version or applied some changes to proxy between me and keystone

 

Thanks

nicholas
Akeeba Staff
Manager

Thank you, that makes more sense now! Keystone always returns headers in Mixed-Case format. However, a proxy or load balancer between the actual Keystone server and your end could indeed lowercase all headers. 

I have already written a fix and will include it in the next version of Akeeba Backup.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

kessenza

Thanks. I found further informations and did some tests. I can confirm that keystone is returning header in mixed case but asking through the proxy they are transformed all lowercase

This is what I found insider haproxy Forum

 

Contrary to a common misconception, header names are not case-sensitive, and
their values are not either if they refer to other header names (such as the
"Connection:" header). In HTTP/2, header names are always sent in lower case,
as can be seen when running in debug mode. Internally, all header names are
normalized to lower case so that HTTP/1.x and HTTP/2 use the exact same
representation, and they are sent as-is on the other side. This explains why an
HTTP/1.x request typed with camel case is delivered in lower case.

 

John

nicholas
Akeeba Staff
Manager

That's exactly what I was thinking was going on.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!