英文:
Using caddy to serve a tracking pixel (base64 encoded)
问题
我正在尝试设置一个非常简单的信标（像素跟踪）服务器。目前我只想让Caddy在每个请求中响应一个1像素的透明gif。URL将被记录，然后我们将解析出我们想要的分析数据。然而，我无法让Caddy提供gif！它显示为损坏的图像。
以下是Caddyfile的内容：
:2015
header Content-Type "image/gif"
header Content-Encoding "base64"
respond /* 200 {
body "R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
close
}
我相信这是一个正确的base64 gif编码。我用以下代码进行了测试：
<body>
[<img src="http://localhost:2015/foo.gif" />]
[<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">]
</body>
如果你加载这个页面，你会看到内联的图片是正常的，但是另一个图片是损坏的。
我不想特别地提供一个实际的文件（或使用file_server或其他任何方法），但是如果这是唯一的方法，那我会这样做。
任何帮助都将是很棒的！
-------------编辑以添加---------
在得到有帮助的评论后，我最终得到了这个简单的Caddyfile来提供一个1像素的图片。我将pix.gif放在/home/patrick/caddplay/temp/pix.gif中，然后将所有请求重写到该位置。看起来工作得很好。
:2015
header Content-Type "image/gif"
handle /* {
root * /home/patrick/caddplay/temp
rewrite * /pix.gif
file_server
}
英文:
I am trying to setup a very simple beacon (pixel tracking) server. Currently all I want to do is have caddy respond with a 1px transparent gif to every request. The URLs will be logged and then we'll parse out the analytics data we're after. However, I can't get Caddy to serve the gif! It appears as a broken image.
Caddyfile
:2015
header Content-Type "image/gif"
header Content-Encoding "base64"
respond /* 200 {
body "R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
close
}
I believe that is the correct encoding for a base64 gif. Tested it with
<body>
[<img src="http://localhost:2015/foo.gif" />]
[<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">]
</body>
If you load that up, you'll see the inline one is fine, but, the other is not.
I don't particularly want to have to serve an actual file (or use file_server or anything else), however, if that's the only way then I'll do it.
Any help would be wonderful!
-------------Edited to add---------
After the helpful comment I ended up with this simple caddyfile to serve a 1px image. I placed the pix.gif inside /home/patrick/caddplay/temp/pix.gif and then rewrite all requests to that. Seems to work just fine.
:2015
header Content-Type "image/gif"
handle /* {
root * /home/patrick/caddplay/temp
rewrite * /pix.gif
file_server
}
答案1
得分: 2
没有浏览器支持将base64作为响应体的content-encoding值，而不是常见的gzip、deflate和br（Brotli）。
如果你追求最高的性能，也许以下建议可以帮助你：
- Caddy应该使用
sendfile，这样内核可以高效地发送你的静态像素文件。实际上，该文件可能会被操作系统在内存中进行透明缓存。尝试一下，看看使用文件作为响应与使用静态字符串相比是否真的有任何开销。 - 我猜你可以将像素放在tmpfs上，这样可以避免在磁盘上进行任何寻址操作，但我想在使用SSD（并且如上所述，通过操作系统在内存中进行缓存）的情况下，这不会带来可衡量的改进。
- 有很多Caddy插件，但我还没有看到一个可以实时解码base64编码字符串的插件，但也许你可以自己创建一个？
* 我所知道的流行浏览器和任何奇特的UA都不支持。
英文:
No* browsers support base64 as a content-encoding value for a response body, as opposed to gzip, deflate and br (Brotli), which are commonplace.
If you're aiming at the highest possible performance, perhaps this can help you:
- Caddy should use
sendfile, so the kernel can send your static pixel file efficiently. The file might actually be transparently cached in memory by your OS. Try and see if there's actually any overhead from responding with a file as opposed to a static string like you're doing now. - I guess you could put the pixel on a tmpfs if you wanted to avoid any seeks on your disk, but I imagine with a SSD (and noted above, caching in memory by the OS) this won't lead to a measurable improvement.
- There are a lot of Caddy plugins, but I haven't seen one that can decode base64-encoded strings on the fly, but perhaps you could create one yourself?
* neither popular browsers nor any esoteric UA I know of.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论