wms_enable_request not working properly

[zanollim]

I have a map file like this:

[...]
WEB
  METADATA
    "ows_enable_request" "*"
[...]
LAYER
  NAME "a"
  METADATA
    "wms_enable_request"    "!GetCapabilities"
  END
[...]
LAYER
  NAME "b"
  METADATA
    "wms_enable_request"    "!GetCapabilities"
  END
[...]
LAYER
  NAME "c"
  METADATA
    "wms_enable_request"    "!GetCapabilities"
  END
[...]
# and so on ...
LAYER
  NAME "z"
  METADATA
    "wms_enable_request"    "!GetCapabilities"
  END

If I request a GetCapabilities the response returns no layer --> correct!

Then I enable, for example, the GetCapabilities inside the layer name "c"

[...]
LAYER
  NAME "c"
  METADATA
    "wms_enable_request"    "GetCapabilities"
  END
[...]

If I request a GetCapabilities the response returns layer c,d,e,...,z --> wrong! I do not see only "c" layer, but all the subsequent layers

[dmorissette]

Checking this now

[dmorissette]

I am unable to reproduce this. In my case I get the right layers. Are you using GROUPs or wms_layer_group in your map? Maybe that could make a difference? Could you please attach a sample mapfile to reproduce the issue?

[zanollim]

Yes I am using GROUPs (not wms_layer_group), sorry I forgot this detail. All layers belong to the same group

for example

[...]
LAYER
  NAME "c"
  GROUP "alphabet"
  METADATA
    "wms_enable_request"    "GetCapabilities"
  END
[...]

Try to assign the layers to the same group, if you even get the right layers, I will attach a sample mapfile

thanks

[dmorissette]

I was able to reproduce the issue by adding the same GROUP name to all layers and committed a fix for the handling of wms_enable_request vs GetCapabilities on GROUPed layers in SVN trunk r11847.

We seem to have the same issue with nested groups (wms_layer_group metadata) but I don't have time to work on it right now. Once that's fixed we'll also need to backport both fixes to the 6.0 branch.

[sholl]

Is this fix already done and backported to 6.0.x?

TIA

[dmorissette]

Nope. No progress since r11847. May be a good one for the FOSS4G sprint since I don't think I'll have time until then anyway.