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 "_"



--
Jody Garnett

On 23 January 2015 at 13:49, David Winslow <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> wrote:
>>
>>> On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <
>>> [email protected]> 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.
>>>
>>> -------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
>
>
> --
> David Winslow
> Software Engineer | Boundless <http://boundlessgeo.com/>
> [email protected]
> 917-388-9085
> @boundlessgeo <http://twitter.com/boundlessgeo/>
>
>
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to