Bugzilla – Full Text Bug Listing
| Summary: | For infocenters running on Eclipse 3.5 and earlier, requests to /rtopic return the page not found input stream, instead of returning SC_NOCONTENT, causing remote help priority to display Topic not found pages even if the doc is not on the infocenter. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jim Perry <perryja> | ||||||||
| Component: | User Assistance | Assignee: | Chris Austin <ChrisAustin> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | cgold, ChrisAustin | ||||||||
| Version: | 4.0 | Flags: | cgold:
review+
|
||||||||
| Target Milestone: | 3.6 RC1 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Jim Perry
Do you have a proposed solution? We're getting towards the end of the Eclipse 3.6 cycle and if we could get a simple low risk solution by the end of Tuesday of next week the fix could get into RC1. As I see it we can detect infocenters which are returning a "page not found" instead of 404, and so if we detect that case and the user selects remote help and read remote help first we can tell when the user is about to get shot in the foot. The question is what to do when we encounter this situation - it seems that we need to inform the user that this will cause problems and change the settings to read local help first. That seems like more than a two or three line change and would need to be done carefully. Created attachment 167757 [details]
Patch to fix remote request failures against pre-3.6 ICs
This patch first checks to see if a remote request IC has an error page (by using an invalid topic). If the remote request returns null, then we store the IC in a table, so that we know requests to this IC already return null as expected. If the remote IC does return an error message page, we store that page, and all future requests to this IC are checked against the error page. If it is a match, we return null.
Chris G - can you do a review on this? There are a couple of things that I think need to change with the patch. The first problem with the patch is that it is using Java 1.5 constructs. Description Resource Path Location Type The method contains(String) is undefined for the type String HelpURLConnection.java /org.eclipse.help.base/src/org/eclipse/help/internal/protocols line 422 Java Problem Description Resource Path Location Type The method contains(String) is undefined for the type String HelpURLConnection.java /org.eclipse.help.base/src/org/eclipse/help/internal/protocols line 423 Java Problem Secondly it should match the extensions from EclipseConnector.requiresErrorPage(), which are "htm", "pdf", "xhtml", "shtml" and "html". I notice that you are testing for a parameter in the URL which is a good idea, EclipseConnector is not doing that so I'm guessing that EclipseConnector would return a 404 instead of showing an error pages if there was a parameter but that is a minor change we may want to make to EclipseConnector. I don't think that the server sees anchors so there is no need to test for those. Created attachment 167788 [details]
Patch V2
I removed the check for extensions, which basically takes care of both the issues you mentioned. It does not impact the outcome of the code. Also, I added some missing stream close() calls.
Created attachment 167796 [details]
Patch V3
Missed an additional close() case.
Patch committed to HEAD. |