Closed GoogleCodeExporter closed 9 years ago
Are you sure about this?
I'm just calling the j2se methods to grab the network headers before they are
sent. I'm not sure where I can have an issue there.
When you publish the code please update the issue with the specific headers so
I can see this in the debugger. Thanks.
Original comment by shai.almog
on 15 Apr 2012 at 4:02
Ya, I'm sure. Here's a sample run, from tcpmon:
POST http://api.twitter.com/oauth/request_token HTTP/1.1
User-Agent: Mozilla/5.0 (Linux; U; Android 2.2; en-us; Nexus One Build/FRF91)
AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Language: en-us
Authorization: OAuth
oauth_callback=<...snip...>,oauth_signature_method="HMAC-SHA1",oauth_timestamp="
1334507148",oauth_version="1.0"
cookie: admobuu=94a18e315fb5e7fbc1f2a8797e5b23ea;_twitter_sess=<...snip...>
Cache-Control: no-cache
Pragma: no-cache
Host: api.twitter.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: keep-alive
Content-Length: 0
And from the network monitor:
cookie=[admobuu=94a18e315fb5e7fbc1f2a8797e5b23ea;_twitter_sess=<...snip...>
Accept-Language=[en-us]
User-Agent=[Mozilla/5.0 (Linux; U; Android 2.2; en-us; Nexus One Build/FRF91)
AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1]
Content-Type=[application/x-www-form-urlencoded; charset=UTF-8]
I'll try to have the blog entry code online later in the week.
Original comment by 1815...@coolman.ca
on 15 Apr 2012 at 4:41
I don't think we can fix it. This is a JavaSE issue:
http://www.docjar.com/html/api/sun/net/www/protocol/http/HttpURLConnection.java.
html
The sun internal class effectively hides some of the headers (authorization)
for security reasons. It inserts the other headers manually right when it
performs the connection.
The problem is that it blocks access to getting the request headers after the
insertion... So effectively there is no way for me to discover these headers
without the proxy. Ugh.
My solution was to change the title in the UI to "Request Headers (Partial
List)" so people won't rely on the data being complete.
I'm closing this as a won't fix because I don't think there is a technical way
to resolve this other than that. The tcpmon approach can be used in parallel to
provide a more complete set of information.
Original comment by shai.almog
on 15 Apr 2012 at 7:40
Shai, a thought just occurred to me here... would it be possible to modify the
NetworkMonitor to behave as a proxy just like Apache TCPMon? In this scenario,
the user enables NetworkMonitor in Simulator, which opens a server socket on a
predefined port (9291 for example), then all network traffic is proxied through
that port, and NetworkMonitor captures the request packets (getting around the
security issue in comment 3) forwards the packet to the desired endpoint,
captures the response, and forwards the response back to the app running in the
simulator.
With something like this in place, I could drop using TCPMon altogether, but
currently too often I'm missing a key piece of info I'm looking for.
Original comment by 1815...@coolman.ca
on 5 Jul 2012 at 4:55
I considered that but the effort seems to be pretty big. Right now I don't
really know anything about the HTTP protocol in my code and just log what I
see. This would require that I actually parse and provide meaningful details.
We need to stop somewhere ;-)
Original comment by shai.almog
on 5 Jul 2012 at 6:49
Original issue reported on code.google.com by
1815...@coolman.ca
on 14 Apr 2012 at 10:08