emma
emma wrote
Reply to Watching Youtube Shorts with Momoka by devtesla
thank you, i was looking for something new to watch
emma wrote
Reply to killed video game by oolong
you gotta lick the goo
emma wrote
Reply to RSS/atom feed issue by voxpoplar
ok so i've looked into this, and on a postmill instance that uses cloudflare + nginx, i cannot reproduce the issue, it seems to work fine. i can only imagine it's a problem between caddy and whatever http client newsblur uses.
emma wrote
Reply to Daily Takane #13: Yukkuri by nitori
this is a yukkuri with no body
also known as a yukkuri
emma wrote
Reply to this is a link with a body by devtesla
that's right
emma OP wrote
emma OP wrote
emma wrote
Reply to comment by Dogmantra in does jstpst have any meme numbers? by twovests
wow, that's like two funny numbers in one
emma wrote
Reply to Your least favorite desserts GO! by Moonside
turkish "delight"
emma wrote
Reply to comment by nitori in Messing with `network.http.referer.spoofSource` in your browser's about:config will impact (un)pinning of posts in Postmill by nitori
i don't think that's desirable. this is one esoteric browser setting i'm not willing to make concessions for.
emma wrote
just like me
emma wrote
Reply to Crouton Art by astaguru
have you considered a contemporary crouton?
emma wrote (edited )
Reply to comment by nitori in Why are browsers not automatically downgrading to HTTP/1 when they encounter a 505 in HTTP/2 or HTTP/3 by nitori
but rereading the spec, you're supposed to send a 505 in the representation used by the major version requested by the client
GET / HTTP/2.0
is parsed with http/1 semantics, so i think it makes sense to give any >= 2.x version the HTTP/1.1 505
treatment.
An HTTP/2 request can be sent without negotiation; this is how h2c (HTTP/2 over cleartext) reliably works for me (for some reason I couldn't get Upgrade from http/1.1 to h2c working). It's called "prior knowledge", and curl supports this.
yeah, but as the name implies, you somehow know in advance that the server's gonna accept HTTP/2 if you send those. i suppose 505 here would make sense, if the HTTP/2 support was ever removed. as i understand it, this mode is never going to happen under normal browsing, though.
No, 505 wouldn't be useful because an HTTP/2 request to an HTTP/1-only server would only result in the client just closing the connection itself. You can see this by using nghttp or curl --http2-prior-knowledge against a server that only supports HTTP/1
An HTTP/2-only client (which those two commands earlier are) would not bother to process an HTTP/1 response (if it even gets one) whether that'd be a 505 or 200.
i meant a hypothetical http/2 that's more http/1-like, not the actual http/2 that came into existence which made it very hard to accidentally use the wrong protocol.
anyway, the solution to your woes is apparently to send an error packet or whatever:
HTTP_1_1_REQUIRED (0x0d):
The endpoint requires that HTTP/1.1 be used instead of HTTP/2.
it sounds like it does what you want, but i have no idea if this applies on the stream or the connection level or what.
emma wrote
Reply to comment by nitori in Why are browsers not automatically downgrading to HTTP/1 when they encounter a 505 in HTTP/2 or HTTP/3 by nitori
I mean the same applies if an HTTP/1 response is a 505, right..?
no, since http/1 requests are sent preemptively without knowing if the server accepts them. http/2+ requests are sent after negotiation, at which point it's established they are accepted. this obsoletes the need for a 505.
505 would have been useful for a future where http/2 requests might be preemptively sent to http/1-only servers. if i send GET / HTTP/2.0
(or any non-1.x version) to nginx, it indeed responds with that status code. but as things turned out, the negotiation mechanism in http/2+ just sidesteps this problem altogether, so 505 ends up being little more than a relic from a time when people didn't know what the future of http held.
since you very much have to opt in for http/2+, incompatibilities with it can be resolved by just not enabling it, and the use cases where one would want partial http/2 support on any given host are extremely contrived, i would argue it's a good thing that support for it is declared on the connection level. it's one less special case for clients to deal with.
emma wrote
hey, that's rude. it's not marc andreessen's fault he looks like that.
emma wrote
Reply to Why are browsers not automatically downgrading to HTTP/1 when they encounter a 505 in HTTP/2 or HTTP/3 by nitori
if a server is able to serve an http response as http/2 and/or http/3, then by definition it supports http/2 and/or http/3, despite the status code's claim of the contrary.
emma wrote
Reply to comment by twovests in Why is the www.jstpst.net only a 302 to jstpst.net by nitori
but sadly, there are no funny ones.
i beg to differ. 320 blaze it.
emma wrote
it's engagement bait so people post about it.
emma wrote
Reply to comment by hollyhoppet in 絶対4℃、C74のCD「COLORS」 by nitori
that's when the good videos were uploaded
emma wrote
Reply to Apparently the project lead of Matrix intentionally shipped side-channel vulnerabilities in their crypto library by nitori
'joke's on you, i knew about the vulnerability all along'
nice one, matt
emma wrote
Reply to comment by 500poundsofnothing in what new events should they add to the summer olympics by hollyhoppet
sounds like a disgusting video. please share the link so i can learn to avoid it.
emma wrote
Reply to "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block" by nitori
i would simply have written my program in a language that had all the features i wanted.
emma wrote
Reply to Jstpst Is Not Shutting Down by twovests
we could also ban touhou