search

RubbaBoy / BYOB

Bring Your Own Badge - Create dynamic README badges based off of your GitHub Actions
MIT License
86 stars 10 forks source link

Badges are no longer displayed #7

Closed simon-ritchie closed 2 years ago

simon-ritchie commented 3 years ago

Hi

Thx for developing BYOB

Recently it seems that the badge is no longer displayed (Includes demo pages: https://github.com/RubbaBoy/BYOBTest), and 400 error is displayed:

image

image

RubbaBoy commented 2 years ago

Well, this is less than ideal. My apologies for putting this off for so long, I meant to get to this a lot earlier. I'm looking into this right now, I've never seen this, especially with a service that has been functional for 2 years.

eapolinario commented 2 years ago

Hey, @RubbaBoy , first of all, I just want to extend my thanks to you for developing this service. This is still happening though, right? Any ideas about what's happening?

eapolinario commented 2 years ago

If I understand the code correctly, we're setting the content type of responses returned by badgen already contain the Content-Type header set to image/svg+xml;charset=utf-8, so maybe this line is making github think the image is invalid when byob runs?

RubbaBoy commented 2 years ago

God damnit, I forgot I put this off. This will now be my priority, I'm very sorry. This is a strange issue that's not openly obvious of what it is, it was working for a long time and then randomly stopped. The headers from badgen are not preserved, it's only the body of the request. I will be looking into this a lot deeper and trying some things on my end.

eapolinario commented 2 years ago

Here's why I commented about the Content-Type header difference between badgen and byob. Let's pick one example for the "same" badge. For example, under the covers the image https://byob.yarr.is/unionai/gh-badges/nightly/core ends up hitting badgen.net at https://badgen.net/badge/_/passing/green?cache=300&icon=github&label=core, right?

Now compare the value of the Content-Type headers in the two responses. First the request to https://byob.yarr.is/unionai/gh-badges/nightly/core:

❯ curl -v 'https://byob.yarr.is/unionai/gh-badges/nightly/core' \
  -H 'authority: byob.yarr.is' \
  -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
  --compressed 2>&1 | grep "content-type"
< content-type: image/svg+xml;charset=utf-8, image/svg+xml

Now compare this with hitting badgen directly:

❯ curl -v 'https://badgen.net/badge/_/passing/green?cache=300&icon=github&label=core' \
  -H 'authority: badgen.net' \
  -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
  --compressed 2>&1 | grep "content-type"
< content-type: image/svg+xml;charset=utf-8

My guess is that the way github is configuring camo (described in step 4 of https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-anonymized-urls#an-image-is-not-showing-up) is doing a stricter match on the value of that header.

RubbaBoy commented 2 years ago

That was an embarrassingly easy fix for the amount of time I previously debugged this and put off looking into this further. The issue was the program was in fact adding onto the headers (I'm really not sure why), so appending the image/svg+xml Content-Type made the field hold two values now, which was invalid according to camo as of September it appears. I don't know why it took this long to fix, and again my apologies to anyone using this program affected by it. And thank you @eapolinario for the assistance, if anyone has any ideas for features I will be happy to do my best in implementing them (as well as giving better support for this program, as I personally am very fond of it).

eapolinario commented 2 years ago

No need to apologize, @RubbaBoy . BYOB is awesome.