configurable path processing strategy

[mcweba]

Problem

The current implementations of the Forwarder and the StorageForwarder perform a path cleanup for every request before forwarding it. This cleanup contains the removal of double slashes. According to RFC3986 Section 3.3 double slashes in URIs are valid and therefore should be respected.

Since the current implementation removes double slashes before handling the request, problems can occur because the client does not expect this behaviour.

This behaviour can be seen clearly in the log statements of the Forwarder and StorageForwarder:

Forwarding request: /playground/server//tests/xx to storage main /playground/server/tests/xx with rule resource_storage

Solution

To not break clients already using this "wrong" behaviour I would suggest to add a http header

x-keep-double-slashes : true

which disables the double slashes removal. Without this header, the behaviour will be unchanged, resulting in the removal of double slashes.

Also a corresponding issue for the vertx-rest-storage has been created. See Issue #40

[lbovet]

I wonder if this should not be a configuration value static for all forwarders. If we keep the choice, it is only for backward compatibility. I don't think that it makes sense to be chosen per-request.

[mcweba]

I would suggest a combination of static configuration and header configuration:

static configuration

property path.processing.strategy
values unmodified, cleaned

header configuration

header x-path-processing-strategy
values unmodified, cleaned

This solution would provide maxium flexibility by defining a default path processing which can be overridden via the header.

Note: The static configuration does not cover our requirements because we have two gateleen instances working together. One should clean the paths while the other should not (for some requests only). Having the static configuration only could break existing behaviour what we don't want to risk.