Bugzilla – Full Text Bug Listing
| Summary: | HTTP Import: log on dialog not show up for some urls | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jane Fang <janefang> | ||||||||||||||||
| Component: | TPTP | Assignee: | Rohit Shetty <rohit.shetty> | ||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||
| Priority: | P1 | CC: | apnan, dnastaci, janefang, jkubasta, labadie, paulslau, sluiman, umarkova | ||||||||||||||||
| Version: | unspecified | Keywords: | plan | ||||||||||||||||
| Target Milestone: | --- | Flags: | apnan:
review+
|
||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Windows XP | ||||||||||||||||||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_206260.html | ||||||||||||||||||
| Whiteboard: | closed460 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Jane Fang
There are two parts if this problem: - a trivial one in which "https://" URLs are discarded. - a non trivial one with the Java authenticator, which is supposed to prompt for user name/password when attempring to opne an input stream which requires authentication, and which doesn't work for the url specified in the defect. Apparently the EcuRep web site is password protected but for some reason java authentication doesn't work. In the tests that we usually run in TPTP we use an Apache web server which is password protected and for which password authentication works. This problem needs furhter investigation. Is this defect required in the fix pack by the consumer? Hi Alex, Denilson has explained to me what happened. The EcuRep sent back 3XX (Redirect), and the new url, which is an https url, is embedede in the header. So the client code needs to check what HTTP status code is returned after sending a request. If it is 2XX, then starts downloading, if it is 3XX, finds the new url and re-sends a request with the new url, etc. Eric requests to fix this defect. Thanks Hi Alex, Please patch the fix for TPTP 4.4.0.3, because the EcuRep/Archive Explorer folks need it now. Thanks Targetting to 4.4.1. Rohit, can you please take a look (start with my prelimiary diagnosis), I am swamped up this week with other tasks. We need to get this done in 4.4.1 and also provide a 4403 patch (read patched jar) for our consumer. Thanks. Created attachment 82417 [details]
Proposed Patch
The patch has been tested for HTTP/HTTPS import and website that contains redirects. Jane, Can you please verify the patch. Thanks. Created attachment 82555 [details]
Updated patch
Created attachment 82560 [details]
Manual test case
Created attachment 82621 [details]
Example log to test
Created attachment 82640 [details]
Updated patch
Patch reviewed and approved. Change defect to enhancement as requested by the PMC and add design doc. Created attachment 83937 [details]
4403 patched org.eclipse.tptp.monitoring.la.core jar
Add 4403 patched org.eclipse.tptp.monitoring.la.core jar
Created attachment 83938 [details]
4403 patched org.eclipse.tptp.monitoring.logui jar
Add 4403 patched org.eclipse.tptp.monitoring.logui jar
why does there need to be a limit of 5 in the redirection support. Granted a typical redirect may only go 2-3 redirects but why a limit at all. Workload balancers etc. can greatly vary the the need. Thats the number of redirections generally supported by browsers, this number cannot be infinity since it might make us susceptible to loop attacks. And Yes, generally you dont see redirections more than twice or thrice. But then i think we should support what browsers support. BTW, there is no impact on performance or any other aspect since this number is 5. The nr of redirection retries limit is documented in section 9.3 Redirection 3xx of rfc1945 http://www.w3.org/Protocols/rfc1945/rfc1945. The latest rfc on http1.1 doesn't seem to specify this limit anymore http://www.ietf.org/rfc/rfc2616.txt, it just mentions it for content developers to be aware of it but emphasises that infinite loops should be detected. AG approved for 4.5 with the following comments: -Since the limit of 5 redirects is somewhat small, can we increase it (e.g. 100). -Please document the limit of redirects in the product documentation. -The documentation sizing is somewhat small (2 hours:). I have added this defect to the 4.5 Plan. I have updated the design doc. and added more doc. time. I've also pointed to the rfc2616 document. We are limiting the redirection retries to 10, which we believe are more then sufficient. Checked in patch (with redirection retries=10) and test cases. (In reply to comment #19) > The latest rfc on http1.1 doesn't seem to specify this limit anymore > http://www.ietf.org/rfc/rfc2616.txt, it just mentions it for content developers > to be aware of it but emphasises that infinite loops should be detected. > I am not sure I would write code based on 11+ year old speculation. I guess my point is more about why we would need to even code a limit. Perhaps a coding style question, but the limit selected is relatively random. I don't see that a user would expose themselves to an "attack". If it takes too long they can cancel the request. We are not providing a general purpose browser or random navigation tool. Documentaion updated. Feature completed. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |