pastie-sane already accepted its browser’s form data. My patch added a file-upload path so a terminal could hand it a file and receive the resulting URL.
The endpoint distinguished two representations of the same data field. Ordinary form data retained its existing response. Multipart file data went through decompression, text validation, and language detection, then received a complete URL with a trailing newline.
For example, a multipart client could use the added root POST route in this shape, with an illustrative host:
curl -F data=@example.py https://paste.example/The upload code tried gzip, then bzip2, then the uncompressed bytes. After successful decompression it removed the recognized compression suffix before guessing a language from the filename. Otherwise example.py.gz could be classified as a compressed object even though the content being displayed was Python source.
It checked that the body decoded as UTF-8. Language selection combined an optional libmagic result, the filename’s MIME guess, normalized MIME aliases, and the submitted MIME type. Plain text was a fallback; a useful specific guess could win over a generic text classification.
That was heuristic display metadata, not a proof of the uploaded language. The implementation also read and decompressed the whole body in memory; this patch supplied neither streaming decompression nor an expanded-size limit. Those are concrete limits of the submitted upload path.
The change merged. The browser’s existing numeric response remained intact.