Given that, I might re-evaluate stopping at 1.1 in the future. But let's keep it there for now.
Why do we not want to force encryption? Because modern encryption algorithms can be dog slow on old 16-bit systems and effectively impossible on 8-bit ones.
But for clients and servers that support it, SSL/TLS encryption will work the same way as it does for HTTP.
> This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?
Because that header is supposed to specify a content type(s). If I were creating a new content type as part of this, I might use it, but the idea is that KyuWeb documents are just Markdown documents, nothing more. Thus `text/markdown` a more correct value for the `Accept` header.
Because HTTP/2 requires encryption. … Or so I thought. As I was double-checking my answer, I found that it looks like that is actually no longer the case: https://http2.github.io/faq/#does-http2-require-encryption
Given that, I might re-evaluate stopping at 1.1 in the future. But let's keep it there for now.
Why do we not want to force encryption? Because modern encryption algorithms can be dog slow on old 16-bit systems and effectively impossible on 8-bit ones.
But for clients and servers that support it, SSL/TLS encryption will work the same way as it does for HTTP.
> This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?
Because that header is supposed to specify a content type(s). If I were creating a new content type as part of this, I might use it, but the idea is that KyuWeb documents are just Markdown documents, nothing more. Thus `text/markdown` a more correct value for the `Accept` header.