On 19-02-16 20:09, Ben Caradoc-Davies wrote:
Niels, I think you are right. Your encoder could be moved to
ResponseUtils so more could benefit, but perhaps the decision to use
it depends on the situation.
Is there an alternative implementation in HttpClient / HttpComponents
already on the cl
On 19 February 2016 at 19:09, Ben Caradoc-Davies wrote:
>
> Also, ResponseUtils.urlEncode and ResponseUtils.urlDecode use:
>>> URLEncoder.encode(value, "ISO-8859-1")
>>> URLDecoder.decode(value, "ISO-8859-1")
>>> which I think should be changed to "UTF-8". Leaving this as
>>> "ISO-8859-1" is goin
But it is not yet on the classpath of this module.
If we do not have a method that does this, we need one that can be shared.
Kind regards,
Ben.
On 20/02/16 08:33, Ben Caradoc-Davies wrote:
> For path encoding, you might consider
> org.apache.http.client.utils.URIBuilder from httpclient 4 if you
For path encoding, you might consider
org.apache.http.client.utils.URIBuilder from httpclient 4 if you think
it will reduce code duplication and the API is convenient in this
situation. It does not encode spaces in paths as "+".
Kind regards,
Ben.
On 20/02/16 08:09, Ben Caradoc-Davies wrote:
>
On 20/02/16 02:07, Niels Charlier wrote:
> On 18-02-16 21:41, Ben Caradoc-Davies wrote:
>> As I hinted above, it might be a very good idea to move your path
>> percent encoding into ResponseUtils.buildURL so all code can benefit.
>> Path elements in URLs muse be encoded when necessary, and until no
Hi Ben,
On 18-02-16 21:41, Ben Caradoc-Davies wrote:
> As I hinted above, it might be a very good idea to move your path
> percent encoding into ResponseUtils.buildURL so all code can benefit.
> Path elements in URLs muse be encoded when necessary, and until now,
> GeoServer has gotten away wit
On 18/02/16 23:23, Robert Coup wrote:
> +1 for absolute URL. I think it'll need to pass through the URLMangler
> process too so that it can get rewritten if necessary for the environment.
Thanks, Robert, that is a very good point.
Niels, all your URL construction must use URLManglers
(Proxifying
On 18-02-16 11:23, Robert Coup wrote:
Personally I'd say "no", because it's pointing to the parent /resource
/rather than it's representation. /?format=/ is a bit of a hack,
/Accept:/ headers are how it's /supposed/ to work in the ideal world ;)
Accept: headers are supported as an alternative.
Hi Ben,
I've made a new PR with percentage encoding as well as following your
suggestion of a full URL in the resource-parent.
I also found that
* percentage decoding isn't happening automatically, had to add this as
well to actually support the percentage encoded paths.
* a bug in the URL link
Hi Ben,
On 18 February 2016 at 05:38, Ben Caradoc-Davies wrote:
> - Should HTTP headers such as Resource-Parent be percent encoded? I
> think so. HTTP forbids all characters outside ISO-8859-1 from headers.
> How are other path fields like Location or Content-Location handled?
> Percent-encoding
On 17/02/16 22:39, Niels Charlier wrote:
> On 16-02-16 21:14, Ben Caradoc-Davies wrote:
>> The encoding of the child href is very thin (only ampersand is
>> replaced). Encoding " to " might give a better error message. And
>> what about percent-encoding? What happens to spaces or # or other
>> char
11 matches
Mail list logo
