uDIG

GetFeatureInfo issued twice

Details

  • Type: Bug Bug
  • Status: Analysis Analysis
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: UDIG 1.1.RC10
  • Fix Version/s: UDIG 1.2.M3
  • Component/s: webservices
  • Labels:
    None

Description

Using the info-tool to pick on an WMS-layer result in two identical GetFeatureInfo requests. One should be enough.

  1. Text File
    UDIG-1272.patch
    14/Oct/10 2:07 AM
    3 kB
    Tore Halset
  2. Text File
    UDIG-1272-1.1.x.patch
    19/Jun/07 4:19 PM
    1 kB
    Tore Halset

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tore Halset added a comment -
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..
Show
Tore Halset added a comment - 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..
Hide
Permalink
Tore Halset added a comment -
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.
Show
Tore Halset added a comment - 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.
Hide
Permalink
Jody Garnett added a comment -
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....
Show
Jody Garnett added a comment - 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....
Hide
Permalink
Tore Halset added a comment -
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?
Show
Tore Halset added a comment - 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?
Hide
Permalink
Jody Garnett added a comment -
We should be able to apply this patch and verify it fices the problem.
Show
Jody Garnett added a comment - We should be able to apply this patch and verify it fices the problem.
Hide
Permalink
Ugo Taddei added a comment -
I've tested the patch and can confirm it fixes the issue.
Show
Ugo Taddei added a comment - I've tested the patch and can confirm it fixes the issue.
Hide
Permalink
Andrea Antonello added a comment -
Applied the patch and committed
Show
Andrea Antonello added a comment - Applied the patch and committed
Hide
Permalink
Tore Halset added a comment -
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.
Show
Tore Halset added a comment - 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.
Hide
Permalink
Ugo Taddei added a comment -
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).
Show
Ugo Taddei added a comment - 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).
Hide
Permalink
Tore Halset added a comment -
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

Show
Tore Halset added a comment - 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
Hide
Permalink
Tore Halset added a comment -
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.
Show
Tore Halset added a comment - 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Tore Halset
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: