[Geoserver-devel] Regression in 2.7.x, valid coverage names are rejected because not valid xml names

[Jukka_Rahkonen]

Hi,

I made a short test with 2.7-beta and found that validation does not actually work just as planned from the UI.

• I changed coverage name “Img_Sample” into “Img Sample” from the UI. Observe that it is possible.

• Checked how the layer/coverage name is advertised in some services:

WMS 1.3.0 nurc:Img Sample

WCS 1.1.1 wcs:IdentifierImg Sample</wcs:Identifier>

WCS 2.0.1 wcs:CoverageIdnurc__Img Sample</wcs:CoverageId>

• The others are OK but I suppose that WCS 2.0.1 is not because the spec mandates that coverageID is NCName and space is not allowed if I understand NCName right. Name would be wrong also as WFS FeatureType name for all versions.

• Tried to change “Img Sample” back to something acceptable but it is not possible from UI. Error is:

“Validation failed with 1 errors. First error message is: Name ‘Img Sample’ is not legal XML’”.

Validation seems to happen in a bit wrong place. First change into invalid name was OK because the original name was acceptable. Second edit fails because the existing name, which is wrong in this state, is checked. I had to edit XML files in data_dir manually before UI could cope with this layer again.

We have a trouble because the default layer name or the edited name from the Basic Resource Info is automatically used in all services. WCS 2.0.1 makes a difference because it tries to build a valid NCName by removing colon and nurc: is changes into nurc__. However, it does not analyze the base name of the layer and not-allowed space is accepted.

Automatic validation and denial is probably too strong operation, but as a user I would appreciate some kind of warnings:

WARNING: ‘137105_CSKS3_DGM_B_HR_01_VV_RA_FF_20141017035343_20141017035413’ is not legal name for the following services:

WFS (all versions)

WARNING: ‘Img Sample’ is not legal name for the following services:

WFS (all versions)

WCS 2.x

WARNING: ‘Img Sample’ name contains characters which can lead to failure with some client programss:

White space,[list other characters].

Perhaps we will need a lookup table that allows fine grained control of advertised layer names in different services and versions.

-Jukka Rahkonen-

-Jukka Rahkonen-

Lähettäjä: Andrea Aime [mailto:andrea.aime@…1268…]
Lähetetty: 22. tammikuuta 2015 15:41
Vastaanottaja: Geoserver-devel
Aihe: Re: [Geoserver-devel] Regression in 2.7.x, valid coverage names are rejected because not valid xml names

···

Ah hem, errata corrige, the commit in question was also silently backported to 2.6.x,

so we have the same regression on the stable series…

Cheers

Andrea

On Thu, Jan 22, 2015 at 12:44 PM, Andrea Aime <andrea.aime@…1268…> wrote:

On Thu, Jan 22, 2015 at 12:37 PM, Andrea Aime <andrea.aime@…1268…> wrote:

On Thu, Jan 22, 2015 at 12:30 PM, Andrea Aime <andrea.aime@…1268…> wrote:

For the record, found the pull, not the discussion:

https://github.com/geoserver/geoserver/pull/786

Found the discussion too:

http://osgeo-org.1560.x6.nabble.com/Layer-and-store-names-td5167890.html

I did agree back then… and I was wrong, probably was thinking just of

invalid feature type names.

Reading though the discussion, we all agreed about some sort of validation, but it did not have

xml safe one.

What about using the xml safe pattern for feature types, and something more relaxed for

everything else, like no spaces, and/or valid file name, or something of the sort?

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

–

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

[David_Winslow]

I think that adding “soft” validation for different services is going to be out of the scope of what I can do for this iteration. The goal here is not specifically to ensure that capabilities documents are valid but to make sure that the links in the REST API are correct/consistent. With this goal in mind I think an appropriate fix would be to validate by testing that the name url-encodes to itself rather than requiring it to be a valid XML element name. This should make the coverages with numeric prefixes valid again and resolve the issue that Andrea brings up.

Jukka, the problem you cited with the Wicket form validating the old value does sound like it needs attention; I will try to correct that also.

···

On Thu, Jan 22, 2015 at 9:35 AM, Rahkonen Jukka (MML) <jukka.rahkonen@anonymised.com> wrote:

Hi,

I made a short test with 2.7-beta and found that validation does not actually work just as planned from the UI.

• I changed coverage name “Img_Sample” into “Img Sample” from the UI. Observe that it is possible.

• Checked how the layer/coverage name is advertised in some services:

WMS 1.3.0 nurc:Img Sample

WCS 1.1.1 wcs:IdentifierImg Sample</wcs:Identifier>

WCS 2.0.1 wcs:CoverageIdnurc__Img Sample</wcs:CoverageId>

• The others are OK but I suppose that WCS 2.0.1 is not because the spec mandates that coverageID is NCName and space is not allowed if I understand NCName right. Name would be wrong also as WFS FeatureType name for all versions.

• Tried to change “Img Sample” back to something acceptable but it is not possible from UI. Error is:

“Validation failed with 1 errors. First error message is: Name ‘Img Sample’ is not legal XML’”.

Validation seems to happen in a bit wrong place. First change into invalid name was OK because the original name was acceptable. Second edit fails because the existing name, which is wrong in this state, is checked. I had to edit XML files in data_dir manually before UI could cope with this layer again.

We have a trouble because the default layer name or the edited name from the Basic Resource Info is automatically used in all services. WCS 2.0.1 makes a difference because it tries to build a valid NCName by removing colon and nurc: is changes into nurc__. However, it does not analyze the base name of the layer and not-allowed space is accepted.

Automatic validation and denial is probably too strong operation, but as a user I would appreciate some kind of warnings:

WARNING: ‘137105_CSKS3_DGM_B_HR_01_VV_RA_FF_20141017035343_20141017035413’ is not legal name for the following services:

WFS (all versions)

WARNING: ‘Img Sample’ is not legal name for the following services:

WFS (all versions)

WCS 2.x

WARNING: ‘Img Sample’ name contains characters which can lead to failure with some client programss:

White space,[list other characters].

Perhaps we will need a lookup table that allows fine grained control of advertised layer names in different services and versions.

-Jukka Rahkonen-

-Jukka Rahkonen-

Lähettäjä: Andrea Aime [mailto:andrea.aime@anonymised.com]
Lähetetty: 22. tammikuuta 2015 15:41
Vastaanottaja: Geoserver-devel
Aihe: Re: [Geoserver-devel] Regression in 2.7.x, valid coverage names are rejected because not valid xml names

Ah hem, errata corrige, the commit in question was also silently backported to 2.6.x,

so we have the same regression on the stable series…

Cheers

Andrea

On Thu, Jan 22, 2015 at 12:44 PM, Andrea Aime <andrea.aime@anonymised.com68…> wrote:

On Thu, Jan 22, 2015 at 12:37 PM, Andrea Aime <andrea.aime@anonymised.com68…> wrote:

On Thu, Jan 22, 2015 at 12:30 PM, Andrea Aime <andrea.aime@anonymised.com68…> wrote:

For the record, found the pull, not the discussion:

https://github.com/geoserver/geoserver/pull/786

Found the discussion too:

http://osgeo-org.1560.x6.nabble.com/Layer-and-store-names-td5167890.html

I did agree back then… and I was wrong, probably was thinking just of

invalid feature type names.

Reading though the discussion, we all agreed about some sort of validation, but it did not have

xml safe one.

What about using the xml safe pattern for feature types, and something more relaxed for

everything else, like no spaces, and/or valid file name, or something of the sort?

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

–

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[Andrea_Aime4]

On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <dwinslow@anonymised.com>
wrote:

I think that adding "soft" validation for different services is going to
be out of the scope of what I can do for this iteration. The goal here is
not specifically to ensure that capabilities documents are valid but to
make sure that the links in the REST API are correct/consistent. With this
goal in mind I think an appropriate fix would be to validate by testing
that the name url-encodes to itself rather than requiring it to be a valid
XML element name. This should make the coverages with numeric prefixes
valid again and resolve the issue that Andrea brings up.

Yes, that sounds like a plan. I'd retain the xml validation for
workspaces/featuretypes, but it's just me.

Jukka, the problem you cited with the Wicket form validating the *old*
value does sound like it needs attention; I will try to correct that also.

Great

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[jive]

Here is a lira covering a subset of this topic (references to workspace styles): http://jira.codehaus.org/browse/GEOS-6811

···

On 22 January 2015 at 10:58, Andrea Aime <andrea.aime@anonymised.com> wrote:

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <dwinslow@anonymised.com> wrote:

I think that adding “soft” validation for different services is going to be out of the scope of what I can do for this iteration. The goal here is not specifically to ensure that capabilities documents are valid but to make sure that the links in the REST API are correct/consistent. With this goal in mind I think an appropriate fix would be to validate by testing that the name url-encodes to itself rather than requiring it to be a valid XML element name. This should make the coverages with numeric prefixes valid again and resolve the issue that Andrea brings up.

Yes, that sounds like a plan. I’d retain the xml validation for workspaces/featuretypes, but it’s just me.

Jukka, the problem you cited with the Wicket form validating the old value does sound like it needs attention; I will try to correct that also.

Great

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

[David_Winslow]

This appears to be describing an unrelated bug. However, the URLEncoder test that I proposed would also prohibit colons so, back to the drawing board. Perhaps rather than try to ensure that encoding is not needed I should review the REST API to make sure that decoding happens properly. It’s a little late in my day to start on such a review but I will investigate next week to see how feasible this is.

···

On Fri, Jan 23, 2015 at 4:34 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is a lira covering a subset of this topic (references to workspace styles): http://jira.codehaus.org/browse/GEOS-6811

–

–
Jody Garnett

On 22 January 2015 at 10:58, Andrea Aime <andrea.aime@anonymised.com> wrote:

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <dwinslow@anonymised.com> wrote:

I think that adding “soft” validation for different services is going to be out of the scope of what I can do for this iteration. The goal here is not specifically to ensure that capabilities documents are valid but to make sure that the links in the REST API are correct/consistent. With this goal in mind I think an appropriate fix would be to validate by testing that the name url-encodes to itself rather than requiring it to be a valid XML element name. This should make the coverages with numeric prefixes valid again and resolve the issue that Andrea brings up.

Yes, that sounds like a plan. I’d retain the xml validation for workspaces/featuretypes, but it’s just me.

Jukka, the problem you cited with the Wicket form validating the old value does sound like it needs attention; I will try to correct that also.

Great

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[jive]

Slightly related - or at least the fix is related. If we change how names are handled it is good to preserve backwards compatibility…

Here was the fix proposed for migrating invalid style names forward while still allowing clients to function.

···

On 23 January 2015 at 13:49, David Winslow <dwinslow@anonymised.com> wrote:

This appears to be describing an unrelated bug. However, the URLEncoder test that I proposed would also prohibit colons so, back to the drawing board. Perhaps rather than try to ensure that encoding is not needed I should review the REST API to make sure that decoding happens properly. It’s a little late in my day to start on such a review but I will investigate next week to see how feasible this is.

–
Jody Garnett

On Fri, Jan 23, 2015 at 4:34 PM, Jody Garnett <jody.garnett@anonymised.com…403…> wrote:

Here is a lira covering a subset of this topic (references to workspace styles): http://jira.codehaus.org/browse/GEOS-6811

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

–
Jody Garnett

On 22 January 2015 at 10:58, Andrea Aime <andrea.aime@anonymised.com> wrote:

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <dwinslow@anonymised.com> wrote:

I think that adding “soft” validation for different services is going to be out of the scope of what I can do for this iteration. The goal here is not specifically to ensure that capabilities documents are valid but to make sure that the links in the REST API are correct/consistent. With this goal in mind I think an appropriate fix would be to validate by testing that the name url-encodes to itself rather than requiring it to be a valid XML element name. This should make the coverages with numeric prefixes valid again and resolve the issue that Andrea brings up.

Yes, that sounds like a plan. I’d retain the xml validation for workspaces/featuretypes, but it’s just me.

Jukka, the problem you cited with the Wicket form validating the old value does sound like it needs attention; I will try to correct that also.

Great

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

[Travis_Brundage]

I’m going to revive this thread a bit as I’m now attempting to start work on [GEOS-6811] and it seems like we have multiple naming issues.

To summarize what I’ve gathered from this thread, it looks like the following names need to be xml safe: featuretypes, workspaces. Everything else, we want to be more lax. We just want to ensure the links in the REST API are consistent/correct. Perhaps anything that is a valid file system name and that does not contain spaces.

I’m not sure how all this will relate to colons in names. What about the fix Jody suggested for invalid style names? Could that be something that’s done generally? A possibility we discussed was having a separate NamesUtilities which would handle the validation/correction of invalid names for these situations.

Is there a ticket for this issue, or should I create one? Probably linking GEOS-6811 especially if the issue/fix is related.

···

On Fri, Jan 23, 2015 at 3:23 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Slightly related - or at least the fix is related. If we change how names are handled it is good to preserve backwards compatibility…

Here was the fix proposed for migrating invalid style names forward while still allowing clients to function.

What about a two stage transitional “fix”:
a) During catalog load notice when a file uses invalid characters and rename the data structure and file to use “" in place of “:”|“&”|“!”|“~” whatever…
b) When a style reference is parsed we can (in a similar fashion) replace illegal characters with an "”

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

–
Jody Garnett

On 23 January 2015 at 13:49, David Winslow <dwinslow@anonymised.com> wrote:

This appears to be describing an unrelated bug. However, the URLEncoder test that I proposed would also prohibit colons so, back to the drawing board. Perhaps rather than try to ensure that encoding is not needed I should review the REST API to make sure that decoding happens properly. It’s a little late in my day to start on such a review but I will investigate next week to see how feasible this is.

On Fri, Jan 23, 2015 at 4:34 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is a lira covering a subset of this topic (references to workspace styles): http://jira.codehaus.org/browse/GEOS-6811

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

–
Jody Garnett

On 22 January 2015 at 10:58, Andrea Aime <andrea.aime@anonymised.com> wrote:

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <dwinslow@anonymised.com> wrote:

I think that adding “soft” validation for different services is going to be out of the scope of what I can do for this iteration. The goal here is not specifically to ensure that capabilities documents are valid but to make sure that the links in the REST API are correct/consistent. With this goal in mind I think an appropriate fix would be to validate by testing that the name url-encodes to itself rather than requiring it to be a valid XML element name. This should make the coverages with numeric prefixes valid again and resolve the issue that Andrea brings up.

Yes, that sounds like a plan. I’d retain the xml validation for workspaces/featuretypes, but it’s just me.

Jukka, the problem you cited with the Wicket form validating the old value does sound like it needs attention; I will try to correct that also.

Great

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

Travis Brundage
Software Engineer | Boundless
tbrundage@anonymised.com
250.888.2820
@boundlessgeo

[Andrea_Aime4]

On Mon, Jan 26, 2015 at 11:36 PM, Travis Brundage <
tbrundage@anonymised.com> wrote:

I'm going to revive this thread a bit as I'm now attempting to start work
on [GEOS-6811] <http://jira.codehaus.org/browse/GEOS-6811&gt; and it seems
like we have multiple naming issues.

To summarize what I've gathered from this thread, it looks like the
following names need to be xml safe: featuretypes, workspaces. Everything
else, we want to be more lax. We just want to ensure the links in the REST
API are consistent/correct. Perhaps anything that is a valid file system
name and that does not contain spaces.

Actually, I've checked around in some installations, and found some that
they are using names starting with numbers also for
feature types and workspaces, and are working just fine. The reason is
simple, they have WFS disabled, and are only serving
data with WMS/WCS/WMTS.

So, even for those I'd say we need some switch to allow xml invalid names
for people that do not need WFS usage.

I'm not sure how all this will relate to colons in names. What about the
fix Jody suggested for invalid style names? Could that be something that's
done generally? A possibility we discussed was having a separate
NamesUtilities which would handle the validation/correction of invalid
names for these situations.

I'm not fully sure about Jody's suggestion. Also see my notes about styles
having a structure like "foo:bar" now being searched as the bar style in
the foo workspace on 2.7.x

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[David_Winslow]

I’ve confirmed that correcting the character handling in REST config addresses the problem that I was trying to solve. It’s a pretty small patch because most of the REST config endpoints already did the decoding and just cascaded WMS layers were missing it. https://github.com/dwins/geoserver/commit/187640942beb6c46f5dc0592fd562202235c158c

Regardless of what is done about issue with colons, I think that we should apply the above patch so that RESTConfig can work with all configurations.

···

On Tue, Jan 27, 2015 at 4:44 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

On Mon, Jan 26, 2015 at 11:36 PM, Travis Brundage <tbrundage@anonymised.com> wrote:

I’m going to revive this thread a bit as I’m now attempting to start work on [GEOS-6811] and it seems like we have multiple naming issues.

To summarize what I’ve gathered from this thread, it looks like the following names need to be xml safe: featuretypes, workspaces. Everything else, we want to be more lax. We just want to ensure the links in the REST API are consistent/correct. Perhaps anything that is a valid file system name and that does not contain spaces.

Actually, I’ve checked around in some installations, and found some that they are using names starting with numbers also for
feature types and workspaces, and are working just fine. The reason is simple, they have WFS disabled, and are only serving
data with WMS/WCS/WMTS.

So, even for those I’d say we need some switch to allow xml invalid names for people that do not need WFS usage.

I’m not sure how all this will relate to colons in names. What about the fix Jody suggested for invalid style names? Could that be something that’s done generally? A possibility we discussed was having a separate NamesUtilities which would handle the validation/correction of invalid names for these situations.

I’m not fully sure about Jody’s suggestion. Also see my notes about styles having a structure like “foo:bar” now being searched as the bar style in the foo workspace on 2.7.x

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[Andrea_Aime4]

On Tue, Jan 27, 2015 at 5:46 PM, David Winslow <dwinslow@anonymised.com>
wrote:

I've confirmed that correcting the character handling in REST config
addresses the problem that I was trying to solve. It's a pretty small
patch because most of the REST config endpoints already did the decoding
and just cascaded WMS layers were missing it.
https://github.com/dwins/geoserver/commit/187640942beb6c46f5dc0592fd562202235c158c

Regardless of what is done about issue with colons, I think that we should
apply the above patch so that RESTConfig can work with all configurations.

Agreed

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[jive]

I am going to write up a proposal for taking our internal names and making them “safe” at the protocol boundaries. The idea may not come together, but I figure I will try.

···

On 27 January 2015 at 08:47, Andrea Aime <andrea.aime@anonymised.com> wrote:

–
Jody Garnett

On Tue, Jan 27, 2015 at 5:46 PM, David Winslow <dwinslow@anonymised.com> wrote:

I’ve confirmed that correcting the character handling in REST config addresses the problem that I was trying to solve. It’s a pretty small patch because most of the REST config endpoints already did the decoding and just cascaded WMS layers were missing it. https://github.com/dwins/geoserver/commit/187640942beb6c46f5dc0592fd562202235c158c

Regardless of what is done about issue with colons, I think that we should apply the above patch so that RESTConfig can work with all configurations.

Agreed

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---

[jive]

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

[David_Winslow]

The proposal to automatically rewrite names seems pretty complicated. I have a number of concerns but I want to focus on just one:

The goal is to eliminate ambiguity but the proposal seems to be adding it. What should happen if a user has an existing configuration with two styles - one named “foo__bar” and another named “foo::bar”? Or generally how do we avoid having multiple “unsafe” names translating to the same “safe” one? I don’t think that it is possible to do this and keep it transparent to old clients.

···

On Tue, Jan 27, 2015 at 1:19 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[jive]

The hope is to prevent the creation of more “unsafe” names on disk (so I do not expect to see foo__bar and foo::bar).
The goal was to recognize we have introduced ambiguity and cut it off before the problem gets worse.

···

On 27 January 2015 at 10:39, David Winslow <dwinslow@anonymised.com> wrote:

The proposal to automatically rewrite names seems pretty complicated. I have a number of concerns but I want to focus on just one:

The goal is to eliminate ambiguity but the proposal seems to be adding it. What should happen if a user has an existing configuration with two styles - one named “foo__bar” and another named “foo::bar”? Or generally how do we avoid having multiple “unsafe” names translating to the same “safe” one? I don’t think that it is possible to do this and keep it transparent to old clients.

–
Jody Garnett

On Tue, Jan 27, 2015 at 1:19 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[Jukka_Rahkonen]

Hi,

I was browsing old tickets from Jira and noticed that there are loads of tickets telling that this or that does not work with REST if layer/store/style etc. names have spaces, dots or other funny characters. Should I try to make a review and collect a list of those?

-Jukka Rahkonen-

···

---

Jody Garnett wrote:

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

[jive]

Maybe link the ticket with a depends on. It will help gather up for test cases.

···

On 29 January 2015 at 11:52, Rahkonen Jukka (MML) <jukka.rahkonen@anonymised.com> wrote:

Hi,

I was browsing old tickets from Jira and noticed that there are loads of tickets telling that this or that does not work with REST if layer/store/style etc. names have spaces, dots or other funny characters. Should I try to make a review and collect a list of those?

-Jukka Rahkonen-

---

Jody Garnett wrote:

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

–
Jody Garnett

[jive]

So how can I kick this along David?

Would you be content if we use this class to:

• Introduce warnings during configuration load
• Lock down the creation of new layers via REST and GUI

I would still like a way to update/fix catalogs:

• Manual: Add to the list of warnings shown to administrators on the welcome page (words to the effect that layer “37A” cannot be used with WFS, click here to provide a valid name")
• Automatic: don’t see any way to do this other than during catalog load, breaking any existing clients

···

On 27 January 2015 at 10:39, David Winslow <dwinslow@anonymised.com> wrote:

The proposal to automatically rewrite names seems pretty complicated. I have a number of concerns but I want to focus on just one:

The goal is to eliminate ambiguity but the proposal seems to be adding it. What should happen if a user has an existing configuration with two styles - one named “foo__bar” and another named “foo::bar”? Or generally how do we avoid having multiple “unsafe” names translating to the same “safe” one? I don’t think that it is possible to do this and keep it transparent to old clients.

–
Jody Garnett

On Tue, Jan 27, 2015 at 1:19 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[jive]

Updated the proposal to be more predictable / less ambitious … https://github.com/geoserver/geoserver/wiki/GSIP-127

···

On 29 January 2015 at 15:52, Jody Garnett <jody.garnett@anonymised.com> wrote:

So how can I kick this along David?

Would you be content if we use this class to:

• Introduce warnings during configuration load
• Lock down the creation of new layers via REST and GUI

I would still like a way to update/fix catalogs:

• Manual: Add to the list of warnings shown to administrators on the welcome page (words to the effect that layer “37A” cannot be used with WFS, click here to provide a valid name")
• Automatic: don’t see any way to do this other than during catalog load, breaking any existing clients

–
Jody Garnett

–
Jody Garnett

On 27 January 2015 at 10:39, David Winslow <dwinslow@anonymised.com> wrote:

The proposal to automatically rewrite names seems pretty complicated. I have a number of concerns but I want to focus on just one:

The goal is to eliminate ambiguity but the proposal seems to be adding it. What should happen if a user has an existing configuration with two styles - one named “foo__bar” and another named “foo::bar”? Or generally how do we avoid having multiple “unsafe” names translating to the same “safe” one? I don’t think that it is possible to do this and keep it transparent to old clients.

On Tue, Jan 27, 2015 at 1:19 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-127

–

David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo

[Andrea_Aime4]

On Fri, Jan 30, 2015 at 1:43 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Updated the proposal to be more predictable / less ambitious ...
https://github.com/geoserver/geoserver/wiki/GSIP-127

I think the proposal sort of goes in the right direction, but it's second
guessing too much the administrator.

If I have a GeoServer that serves only WMS, I might not want to have any
restriction on names.

If instead I have WFS enabled, then the workspace and feature type names
should be checked for compatibility.

If I have WCS enabled, and in particular intend to use WCS 2.0, also
coverage names need to be sanitized (they
have to be NCNAME), but if I don't care about it, again, no limitations.

So I believe these checks should be configurable, or at least contextual.
Like maybe a checkbox to have
strict name validation in the respective services, enabled by default in
the newer versions of GeoServer,
that would enable the validator to run if checked, and the associated
service enabled.

The name migration should not be automatic, but again, controlled by the
administrator, which can decided
if she likes what's going on, or decide this would ruin the datadir
existing clients using the service, and
decide to keep on working with invalid names

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[jive]

Establishing a new level of control here is a bit of a reach when we are trying to close a validation gap?

How about I take migration out of the proposal, and we warn users when they are publishing with an invalid name (and the warning can provide the name that will actually be seen).

So for a FeatureType 13A the warning will say "13A is not valid, will be published as the “_13A”.

I don’t think we want to reach in and disable layers on a protocol by protocol basis.

···

On 30 January 2015 at 07:11, Andrea Aime <andrea.aime@anonymised.com> wrote:

–
Jody Garnett

On Fri, Jan 30, 2015 at 1:43 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Updated the proposal to be more predictable / less ambitious … https://github.com/geoserver/geoserver/wiki/GSIP-127

I think the proposal sort of goes in the right direction, but it’s second guessing too much the administrator.

If I have a GeoServer that serves only WMS, I might not want to have any restriction on names.

If instead I have WFS enabled, then the workspace and feature type names should be checked for compatibility.

If I have WCS enabled, and in particular intend to use WCS 2.0, also coverage names need to be sanitized (they
have to be NCNAME), but if I don’t care about it, again, no limitations.

So I believe these checks should be configurable, or at least contextual. Like maybe a checkbox to have
strict name validation in the respective services, enabled by default in the newer versions of GeoServer,
that would enable the validator to run if checked, and the associated service enabled.

The name migration should not be automatic, but again, controlled by the administrator, which can decided
if she likes what’s going on, or decide this would ruin the datadir existing clients using the service, and
decide to keep on working with invalid names

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

---