# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 13
# self = https://watcher.sour.is/conv/y2t2tnq
Now WTF!? Suddenly, @falsifian's feed renders broken in my tt Python implementation. Exactly what I had with my Go rewrite. I haven't touched the Python stuff in ages, though. Also, tt and tt2 do not share any data at all.

By any chance, did you remove the ; charset=utf-8 from your Content-Type: text/plain header, falsifian?

interpreted in some crappy windows charset
@lyse Sorry, I don't think I ever had charset=utf8. I just noticed that a few days ago. OpenBSD's httpd might not support including a parameter with the mime type, unfortunately. I'm going to look into it.=
It should be fixed now. Just needed some unusual quoting in my httpd.conf: https://mail-archive.com/misc@openbsd.org/msg169795.html
@falsifian I can confirm, it's fixed. Thank you! Indeed, this is some wild quoting.

I still do not understand why the encoding suddenly broke, though. :-? Anyway. I concentrate on my rewrite and do things the rightβ„’ way. ;-) Still long ways to go.
@lyse Just as an aside, shouldn't you assume utf-8 anyway these days if not specified? πŸ€” I mean basically everything almost always uses utf-8 encoding right? πŸ˜…
@lyse Just as an aside, shouldn't you assume utf-8 anyway these days if not specified? πŸ€” I mean basically everything almost always uses utf-8 encoding right? πŸ˜…
@prologic text/plain without an explicit charset is still just US-ASCII:

> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.

https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
@prologic text/plain without an explicit charset is still just US-ASCII:

> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.

https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
@prologic text/plain without an explicit charset is still just US-ASCII:

> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.

https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
@prologic text/plain without an explicit charset is still just US-ASCII:

> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.

https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
@movq Fair πŸ‘Œ
@movq Fair πŸ‘Œ
@prologic I wish that was true! But I reckon there is still heaps of old stuff out there, that was created on a Windows machine. :-D And I wouldn't be surprised if even today in that environment a new file does not make use of UTF-8.