Closed titobrasolin-ke closed 2 years ago
Does this work on BusyBox?
echo "HeAdEr-NaMe: SoMeThInG : something" | awk -F: '{ st = index($0, ":"); print tolower($1) ":" substr($0, st + 1)}'
The output looks good to me:
header-name: SoMeThInG : something
Try busybox-compat
branch and let me know. Please also share examples how did you test that it works.
Just kindly confirm if it works well. It could be great if it is the only things that break it on busybox.
Thank you @sormy Forgive my slowness in responding, I'm usually offline for most of the day. I did a quick test with AWS IoT DescribeThing https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeThing.html
I tried busybox-compat
and noticed an extra ":" in $CANONICAL_HEADERS
* SIGV4 Canonical Request:
GET
/things/thingName
:
host:iot.eu-central-1.amazonaws.com
x-amz-date:20220927T073853Z
[...]
{"message":"The request signature we calculated does not match the signature you provided...
I added a check on st
, like this:
| awk -F: '{ st = index($0, ":"); if ( st > 0 ) print tolower($1) ":" substr($0, st + 1)}' \
It works well:
* SIGV4 Canonical Request:
GET
/things/thingName
host:iot.eu-central-1.amazonaws.com
x-amz-date:20220927T075037Z
[...]
{"attributes":{"device_id":"...
Important note: I'm allowed to install additional packages on the device but cannot rebuild the system (an old OpenWrt 18). BusyBox has been built without od
and paste
support, I'm actually using the coreutils-od
and coreutils-paste
packages. On the other hand the sed
package is not available for OpenWrt 18.
The change is merged to master, resolving
To give a concrete example, OpenWrt is normally distributed with BusyBox sed, not GNU sed. Because of this the otherwise perfect script fails due to the lack of GNU extensions. For instance "\L" and "\E" are not supported:
https://github.com/sormy/aws-curl/blob/f992d85735daa6008e0cb893ef079b2eae225e60/aws-curl#L184
I understand that this is a problem limited to a few niche situations, so please close the issue directly if the implementation is too laborious.
Thanks @sormy