A proposal for an HTTP stream capture mechanism

2009-04-23 Thread Jean-Christophe Collet
I have been working on adding better logging and debugging tools to the 
HTTP implementation.
A significant chunk of the bugs that we have to investigate are HTTP 
related and being able to monitor the traffic has always been a problem. 
Using a packet sniffer is cumbersome and not always possible.
So I have been putting together a prototype to make that a lot easier. 
The idea is to be able to turn on traffic capture with a system property 
and a simple "rule" file.


The idea is that you can specify a set of capture rules in a file and 
point to that file with the property 'sun.net.http.captureRules'
The rule file has a simple syntax. 1 rule per line. A line starting with 
a '#' is a comment and is ignored. A rule is a comma separated pair 
regular-expression , file pattern.

e.g.:

http://www\.sun\.com , sun%d.log

tells to capture traffic for all URLs containing http://www.sun.com and 
to dump that traffic into a file sunxx.log (the xx is a randomly 
generated number that ensures the created file doesn't overwrite an 
existing one. Of course that '%d' is optional. If the files exist, then 
every capture is appended to it (which might not be a good idea in case 
of multiple parallel threads).


So to capture all the traffic into a single file, the rule would be:

.* , http.log

A usage example becomes:

$ java -Dsun.net.http.captureRules=capture-rules GetURL http://www.sun.com

where 'capture-rules' is the file containing my set of rules.

I have a first prototype of this working but I'm still refining it. I'll 
publish a webrev in a few days.


Comments?





Re: A proposal for an HTTP stream capture mechanism

2009-04-23 Thread Max (Weijun) Wang

Hi Jessie

This is very useful.

What kind of info are dumped? Content and/or headers?

Can you also capture the connection info? Sometimes I need to know if  
a new connection is created or the old one is reused.


The \. in sun\.com looks a little cumbersome. I know .hgignore  
supports several different pattern matching mechanisms, probably worth  
a look?


Thanks
Max


On Apr 23, 2009, at 10:02 PM, Jean-Christophe Collet wrote:

I have been working on adding better logging and debugging tools to  
the HTTP implementation.
A significant chunk of the bugs that we have to investigate are HTTP  
related and being able to monitor the traffic has always been a  
problem. Using a packet sniffer is cumbersome and not always possible.
So I have been putting together a prototype to make that a lot  
easier. The idea is to be able to turn on traffic capture with a  
system property and a simple "rule" file.


The idea is that you can specify a set of capture rules in a file  
and point to that file with the property 'sun.net.http.captureRules'
The rule file has a simple syntax. 1 rule per line. A line starting  
with a '#' is a comment and is ignored. A rule is a comma separated  
pair regular-expression , file pattern.

e.g.:

http://www\.sun\.com , sun%d.log

tells to capture traffic for all URLs containing http://www.sun.com  
and to dump that traffic into a file sunxx.log (the xx is a  
randomly generated number that ensures the created file doesn't  
overwrite an existing one. Of course that '%d' is optional. If the  
files exist, then every capture is appended to it (which might not  
be a good idea in case of multiple parallel threads).


So to capture all the traffic into a single file, the rule would be:

.* , http.log

A usage example becomes:

$ java -Dsun.net.http.captureRules=capture-rules GetURL http://www.sun.com

where 'capture-rules' is the file containing my set of rules.

I have a first prototype of this working but I'm still refining it.  
I'll publish a webrev in a few days.


Comments?







Re: A proposal for an HTTP stream capture mechanism

2009-04-23 Thread Jean-Christophe Collet

Max (Weijun) Wang wrote:

Hi Jessie

This is very useful.

What kind of info are dumped? Content and/or headers?


What is dumped is the entire stream, byte for byte, captured at the TCP 
socket level. So, includes request, headers and body. Both ways.


This is supposed to complement the traditional logging of events that is 
being extended as well.
So HttpURLConnection is getting some new logging entries as well as an 
optional Formatter for these entries.I attached an example of the 
created log (independent of the capture mentioned earlier).


What the dump now permits is easy comparison between the raw data (from 
the capture rules) and how it was interpreted by HttpURLConnection (from 
the logging).




Can you also capture the connection info? Sometimes I need to know if 
a new connection is created or the old one is reused.


This is now part of the "normal" log.



The \. in sun\.com looks a little cumbersome. I know .hgignore 
supports several different pattern matching mechanisms, probably worth 
a look?


The idea is to use regular expressions to allow for maximum flexibility 
AND simpler implementation.




Thanks
Max


On Apr 23, 2009, at 10:02 PM, Jean-Christophe Collet wrote:

I have been working on adding better logging and debugging tools to 
the HTTP implementation.
A significant chunk of the bugs that we have to investigate are HTTP 
related and being able to monitor the traffic has always been a 
problem. Using a packet sniffer is cumbersome and not always possible.
So I have been putting together a prototype to make that a lot 
easier. The idea is to be able to turn on traffic capture with a 
system property and a simple "rule" file.


The idea is that you can specify a set of capture rules in a file and 
point to that file with the property 'sun.net.http.captureRules'
The rule file has a simple syntax. 1 rule per line. A line starting 
with a '#' is a comment and is ignored. A rule is a comma separated 
pair regular-expression , file pattern.

e.g.:

http://www\.sun\.com , sun%d.log

tells to capture traffic for all URLs containing http://www.sun.com 
and to dump that traffic into a file sunxx.log (the xx is a 
randomly generated number that ensures the created file doesn't 
overwrite an existing one. Of course that '%d' is optional. If the 
files exist, then every capture is appended to it (which might not be 
a good idea in case of multiple parallel threads).


So to capture all the traffic into a single file, the rule would be:

.* , http.log

A usage example becomes:

$ java -Dsun.net.http.captureRules=capture-rules GetURL 
http://www.sun.com


where 'capture-rules' is the file containing my set of rules.

I have a first prototype of this working but I'm still refining it. 
I'll publish a webrev in a few days.


Comments?







HTTP: ProxySelector Request for http://www.sun.com/
HTTP: Proxy used: DIRECT
HTTP: CookieHandler request for http://www.sun.com/
HTTP: Cookies from handler:
HTTP:   GET / HTTP/1.1
User-Agent: Java/1.7.0-internal
Host: www.sun.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP:   HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Thu, 23 Apr 2009 12:39:40 GMT
P3p: policyref="http://www.sun.com/p3p/Sun_P3P_Policy.xml";, CP="CAO DSP 
COR CUR ADMa DEVa TAIa PSAa PSDa CONi TELi OUR  SAMi PUBi IND PHY ONL PUR COM 
NAV INT DEM CNT STA POL PRE GOV"
Cache-control: public
Proxy-agent: Sun-Java-System-Web-Server/7.0
X-powered-by: Servlet/2.4
X-powered-by: JSP/2.0
Set-cookie: JSESSIONID=d2fd0a01da80e724dd7302199f517; Path=/
Content-type: text/html;charset=UTF-8
Via: 1.1 https-www
Set-cookie: JROUTE=1p6hcsERNu5+EQvn; Path=/
Transfer-encoding: chunked
HTTP: ProxySelector Request for http://www.sun.com/products
HTTP: Proxy used: DIRECT
HTTP: CookieHandler request for http://www.sun.com/products
HTTP: Cookies from handler:
ROUTE=1p6hcsERNu5+EQv
SESSIONID=d2fd0a01da80e724dd7302199f51
HTTP:   GET /products HTTP/1.1
User-Agent: Java/1.7.0-internal
Host: www.sun.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Cookie: JROUTE=1p6hcsERNu5+EQvn; 
JSESSIONID=d2fd0a01da80e724dd7302199f517
HTTP:   HTTP/1.1 301 Moved Permanently
Server: Sun-Java-System-Web-Server/7.0
Date: Thu, 23 Apr 2009 12:39:41 GMT
P3p: policyref="http://www.sun.com/p3p/Sun_P3P_Policy.xml";, CP="CAO DSP 
COR CUR ADMa DEVa TAIa PSAa PSDa CONi TELi OUR  SAMi PUBi IND PHY ONL PUR COM 
NAV INT DEM CNT STA POL PRE GOV"
Location: /products/index.jsp
Content-length: 0
HTTP: Redirected from http://www.sun.com/products to 
http://www.sun.com/products/index.jsp
HTTP: ProxySelector Request for http://www.sun.com/products/index.jsp
HTTP: Proxy used: DIRECT
HTTP: CookieHandler request for http://www.sun.co

hg: jdk7/tl/jdk: 6832557: TEST_BUG: java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java fails to compile

2009-04-23 Thread alan . bateman
Changeset: 057e4afcf978
Author:alanb
Date:  2009-04-23 19:44 +0100
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/057e4afcf978

6832557: TEST_BUG: 
java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java fails to 
compile
Reviewed-by: darcy, mcimadamore

! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java



Re: A proposal for an HTTP stream capture mechanism

2009-04-23 Thread Weijun Wang
>> What kind of info are dumped? Content and/or headers?
> 
> What is dumped is the entire stream, byte for byte, captured at the TCP
> socket level. So, includes request, headers and body. Both ways.

Is it easy to read?

Thanks
Max