[bug] language setting causes invalid value for header? #503

New Issue

Open

opened 2023-03-11 13:10:05 +00:00 by yheuhtozr · 4 comments

yheuhtozr commented

2023-03-11 13:10:05 +00:00

Your setup

OTP

Extra details

No response

Version

3.6.0

PostgreSQL version

What were you trying to do?

I try to remote repeat or do any interaction with a post through web UI, for example this one:

then:

What did you expect to happen?

When I input my account ID, it redirects to my instance and the server takes care of it.

What actually happened?

My instance's ostatus_subscribe page displays "Error fetching user", and the following error is logged in my service journal.

I'm not exactly sure it is caused by BE, FE, or my browser's language settings.

Logs

Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not decode user at fetch https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\""
Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not fetch user https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, {nil, {:error, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\""}}

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup OTP ### Extra details _No response_ ### Version 3.6.0 ### PostgreSQL version 14 ### What were you trying to do? I try to remote repeat or do any interaction with a post through web UI, for example this one: ![image](/attachments/ee5cd6f3-37a8-421f-9940-a5ea43e069d1) then: ![image](/attachments/449b82fe-f8d3-4cb7-8052-c614e380649f) ### What did you expect to happen? When I input my account ID, it redirects to my instance and the server takes care of it. ### What actually happened? My instance's `ostatus_subscribe` page displays "Error fetching user", and the following error is logged in my service journal. I'm not exactly sure it is caused by BE, FE, or my browser's language settings. ### Logs ```shell Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not decode user at fetch https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\"" Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not fetch user https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, {nil, {:error, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\""}} ``` ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

image.png

20 KiB

image.png

98 KiB

yheuhtozr added the

bug

label 2023-03-11 13:10:05 +00:00

floatingghost commented

2023-03-11 17:20:45 +00:00

Owner

interesting, i wonder if that's caddy doing weird stuff

floatingghost commented

2023-03-11 17:23:57 +00:00

Owner

curl https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 -D- --header "Accept-Language: ja"
seems to throw back a correctly formatted header
hm

curl https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 -D- --header "Accept-Language: ja" seems to throw back a correctly formatted header hm

yheuhtozr commented

2023-03-12 03:06:32 +00:00

Author

Just noticed that when I change my account's interface language (on Akkoma-FE), the error is gone. But now ostatus_subscribe returns "Error following account" and still can't repeat that post. This time there seems no error recorded in the journal or the access log.

FYI:

YOUR.IP.AD.DR - - [12/Mar/2023:12:01:23 +0900] "GET /ostatus_subscribe?acct=https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 HTTP/2.0" 200 511 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0"

Just noticed that when I change my **account's** interface language (on Akkoma-FE), the error is gone. But now `ostatus_subscribe` returns "Error following account" and still can't repeat that post. This time there seems no error recorded in the journal or the access log. --- FYI: ``` YOUR.IP.AD.DR - - [12/Mar/2023:12:01:23 +0900] "GET /ostatus_subscribe?acct=https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 HTTP/2.0" 200 511 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0" ```

Clovis commented

2023-08-07 12:13:00 +00:00

Contributor

While trying to follow a relay, I encountered the same error. I was able to mitigate it by deactivating the ActivityPub.SignObjectFetch setting.

From what I understand, this bug is encountered on non-english servers because of those lines:

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L271-L276

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L230-L236

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80

Having the Pleroma.Config.get([:activitypub, :sign_object_fetches]) set to true cause the server to add a Date header on its requests. However, it seems that this date is translated at some point (probably following OS locale settings). On my config it generates lun., 07 août 2023 10:32:16 GMT with "û" not being a valid ASCII char.

This bug seems to be rather important since in the current state, we do not follow the Date HTTP header format in some cases: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date

Here is the fix I'll propose in a PR (https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80):

  def signed_date(%NaiveDateTime{} = date) do
    Timex.lformat!(date, "{WDshort}, {0D} {Mshort} {YYYY} {h24}:{m}:{s} GMT", "en")
  end

While trying to follow a relay, I encountered the same error. I was able to mitigate it by deactivating the `ActivityPub.SignObjectFetch` setting. From what I understand, this bug is encountered on non-english servers because of those lines: https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L271-L276 https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L230-L236 https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80 Having the `Pleroma.Config.get([:activitypub, :sign_object_fetches])` set to true cause the server to add a `Date` header on its requests. However, it seems that this date is translated at some point (probably following OS locale settings). On my config it generates `lun., 07 août 2023 10:32:16 GMT` with "û" not being a valid ASCII char. This bug seems to be rather important since in the current state, we do not follow the Date HTTP header format in some cases: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date Here is the fix I'll propose in a PR (https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80): ``` def signed_date(%NaiveDateTime{} = date) do Timex.lformat!(date, "{WDshort}, {0D} {Mshort} {YYYY} {h24}:{m}:{s} GMT", "en") end ```