# Revision history [back]

Looking at the tests above, I see that all of the identifiers of those that fail have a "/" (forward slash) in them, so there is a problem with how these identifiers are interpreted by the web service. Many web servers for security reasons alter URLs such as foo/../../../somewhere/outside/web/context to maintain the context of the request, so that would be my leading guess of where the problem lies.

Checking the exception text:

ServiceFailure: 0000: NON-D1-EXCEPTION: status: 404 response headers:
Vary = Accept-Encoding
Date = Tue, 02 Apr 2013 18:49:5...: path-ascii-doc-example-10.1000/182


it seems an unexpected response was received - so either the service returns non-dataone exceptions in some cases, or the request never reached the dataone service and the web server returned it.

Putting it all together, my hunch is that it is the latter - the web server itself is failing to pass the request on to the DataONE handler, and returning a standard response. I would look at how your web server is handling security for these types of requests.

If you are using apache/tomcat, try adding the following lines to catalina.properties

org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true


In general, the main culprits are either how your code handles the identifier (whether it can handle unicode characters properly), or how the web server handles the URL.

Looking at the tests above, I see that all of the identifiers of those that fail have a "/" (forward slash) in them, so there is a problem with how these identifiers are interpreted by the web service. Many web servers for security reasons alter URLs such as foo/../../../somewhere/outside/web/context to maintain the context of the request, so that would be my leading guess of where the problem lies.

Checking the exception text:

ServiceFailure: 0000: NON-D1-EXCEPTION: status: 404 response headers:
Vary = Accept-Encoding
Date = Tue, 02 Apr 2013 18:49:5...: path-ascii-doc-example-10.1000/182


it seems an unexpected response was received - so either the service returns non-dataone exceptions in some cases, or the request never reached the dataone service and the web server returned it.

Putting it all together, my hunch is that it is the latter - the web server itself is failing to pass the request on to the DataONE handler, and returning a standard response. I would look at how your web server is handling security for these types of requests.

If you are using apache/tomcat, try adding the following lines to catalina.properties

org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true