Changes between Initial Version and Version 1 of Ticket #12778, comment 4


Ignore:
Timestamp:
Dec 26, 2014, 8:52:11 AM (4 years ago)
Author:
dcf
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12778, comment 4

    initial v1  
    2828> It doesn't look like there's much in either case that we have control over. Both have Content-Type: application/octet-stream, even though the server does not set that header explicitly. It's probably being done implicitly by [http://golang.org/pkg/net/http/#DetectContentType http.DetectContentType].
    2929
    30 It turns out that even if you disable the Content-Type header at meek-server (with `w.Header()["Content-Type"] = nil`), Google and Amazon will just add it back anyway. And when the response body is empty, they will set it to "text/plain; charset=utf-8", which is even longer than "application/octet-stream". So in [https://gitweb.torproject.org/pluggable-transports/meek.git/commitdiff/fa5fbb807a5d81cd234caf402f262d4a5de0533e fa5fbb807a5d81cd234caf402f262d4a5de0533e] I just set the Content-Type header unconditionally.
     30It turns out that even if you disable the Content-Type header at meek-server (with `w.Header()["Content-Type"] = nil`), Google and Amazon will just add it back anyway. And when the response body is empty, they will set it to "text/plain; charset=utf-8", which is even longer than "application/octet-stream". So in [https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=fa5fbb807a5d81cd234caf402f262d4a5de0533e fa5fbb807a5d81cd234caf402f262d4a5de0533e] I just set the Content-Type header unconditionally.