[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send
#22865: Explicitly set Content-Length to zero when there is no data to send
------------------------------+------------------------------
Reporter: twim | Owner: dcf
Type: defect | Status: needs_review
Priority: Medium | Milestone:
Component: Obfuscation/meek | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
------------------------------+------------------------------
Comment (by dcf):
I've just done a test here locally, and meek-client compiled with `go1.8.3
linux/amd64` sends `Content-Length: 0` even without the patch from this
ticket. I inspected the traffic by running a socat shim on port 4000:
{{{
socat -v -v TCP-LISTEN:4000,fork,reuseaddr OPENSSL:xxx.appspot.com:443
}}}
Then I configured tor to connect through 127.0.0.1:4000
{{{
UseBridges 1
ClientTransportPlugin meek exec ./meek-client --log meek-client.log
Bridge meek 0.0.2.0:3 url=http://xxx.appspot.com/ front=127.0.0.1:4000
}}}
The socat output contains examples like this:
{{{
POST / HTTP/1.1\r
Host: meek-reflect-test.appspot.com\r
User-Agent: Go-http-client/1.1\r
Content-Length: 0\r
X-Session-Id: Mv2/KXfE3mE\r
Accept-Encoding: gzip\r
\r
}}}
Are you able to reproduce this? I don't see how the patch would cause it
to behave any differently. And the documentation for
[https://golang.org/pkg/net/http/#NewRequest http.NewRequest] says that a
*bytes.Reader has special handling and sets the body to the magic value
[https://golang.org/pkg/net/http/#pkg-variables NoBody] when the length of
the Reader is 0:
> If body is of type *bytes.Buffer, *bytes.Reader, or *strings.Reader, the
returned request's ContentLength is set to its exact value (instead of
-1), GetBody is populated (so 307 and 308 redirects can replay the body),
and Body is set to NoBody if the ContentLength is 0.
So I'm wondering if this patch is really needed? If so, can you give me
complete reproduction instructions so that I can see the bug for myself?
----
Replying to [comment:6 twim]:
> Seems to be not a bug. This is now persistent behavior at Google
AppEngine Flexible Environment. Most likely it was being upgraded at that
moment. Standard Environment works as before (without inspection
middleware).
I'm confused now by your references to the flexible environment. I tried
deploying reflect.go to the flexible environment by adding `env: flex` to
app.yaml:
{{{
env: flex
runtime: go
api_version: go1
automatic_scaling:
max_idle_instances: 2
min_pending_latency: 1000ms
handlers:
- url: /.*
script: _go_app
secure: always
}}}
However that caused `gcloud app deploy` to display an error message:
{{{
2017/07/15 13:04:04 failed analyzing meek/appengine: the root of your app
needs to be package "main" (currently "reflect")
}}}
If I change the package name from `"reflect"` to `"main"`, I get another
error:
{{{
2017/07/15 13:05:45 failed analyzing meek/appengine: cannot find package
"appengine" in any of:
...
}}}
So it seems that reflect.go needs more extensive changes than just
attachment:0001-Explicitly-set-Content-Length-to-zero-when-there-
is-.patch in order to run in the flexible environment. Are you running
something other than reflect.go on App Engine?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22865#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs