GetFeatureInfo issued twice

Tore Halset added a comment - 19/Jun/07 4:19 PM The problem seem to be that WMSDescribeLayer inner subclass of LayerPointInfo expose two different ways to connect to the URL. 1) getRequestURL() - provide a way to get to the same URL several times. 2) getResponse() - a nice lazy fetch keeping the response. BrowserInfoDisplay uses (before this patch) getRequestURL() to get the URL and get the content, but the content are already fetched by #2 above. The problem is still not solved as others my use getRequestURL() and open their own connection. Something like that..

Tore Halset added a comment - 19/Jun/07 4:33 PM An added benefit to the solution in the patch is for authenticated GetFeatureInfo requests as the users do not need to provide a new username/password for the embedded browser. However, if the returned html links to other items protected with http basic authentication, the user will still have to provide the username and password to the embedded browser.

Jody Garnett added a comment - 19/Jun/07 7:57 PM But it is not .. the first request should have the HTTP Headers configured to only ask for the kind of content returned. Based on that answer we embed a browser - which makes the second request. If the returned type had been some flavour of GML we would of asked for the content and placed it in a feature viewer etc....

Tore Halset added a comment - 20/Jun/07 12:53 AM Okay, so uDig has to issue (at least for info format = html) GetFeatureRequest twice then? Why not give the embedded browser the content from the first request?

Jody Garnett added a comment - 07/Mar/09 8:28 AM We should be able to apply this patch and verify it fices the problem.

Ugo Taddei added a comment - 14/Mar/09 1:51 PM I've tested the patch and can confirm it fixes the issue.

Andrea Antonello added a comment - 15/Mar/09 1:36 AM Applied the patch and committed

Tore Halset added a comment - 26/Mar/09 7:32 AM I am sorry, but this fix introduced two new problems found in 1.2-M3. Extra sorry since I provided the bad patch.. 1. Relative links like /logo.png does not work. 2. non-latin-1 chars like some greek characters does not display correctly. My suggestion is that someone with commit access revert the patch and then I or someone else can look for a better solution.

Ugo Taddei added a comment - 26/Mar/09 8:05 AM Without checking... I bet browser.setUrl( info.getRequestURL().toString() ); is better than browser.setText((String) info.acquireValue()); (s. patch) because the former might handle enconding properly (assuming this is an encoding problem).

Tore Halset added a comment - 26/Mar/09 9:11 AM Yes, browser.setUrl( info.getRequestURL().toString() ) is working fine, but can we issue that *without* fetching the content one extra time before the browser? Before - double fetching  * fetch content from the server  * look at content type and see if the browser can handle that mime type  * tell the browser to fetch the content from the server Fix with the two problems  * fetch content from the server  * give content to browser Another option could be something like:  * look at INFO_FORMAT and see if the browser can handle the format (ie text/html)  * tell the browser to fetch the content from the server

Tore Halset added a comment - 14/Oct/10 2:07 AM Added a patch (UDIG-1272.patch) that still uses only one request for GetFeatureInfo, but fixes the problem with character set and relative links in html. It does this by using the INFO_FORMAT in the request to determine if the response will be plain text or html. This should be fine as the used INFO_FORMAT is from the capabilities.