bodar / utterlyidle Goto Github PK

If a client explicitly sets a response code to 200 but then returns no content, this is overridden and a 204 is returned instead of the explicitly set 200.

Running the build via Git Bash (uses Msys, I think), both the Base64EncodingTest and EncodingCookieHandlerTest fail with errors like these:

Expected: is "SMWNYiBOxZHhuIM="
but: was "SD9iIE4/Pw==""

Unencoding that results in H?b N??, indicating the string encoding is probably not respecting Unicode characters.

As ClientHttpHandler uses HttpUrlConnection under the hood the certain headers are silently dropped because they are restricted in W3C XMLHttpRequest2 (browsers). UtterlyIdle is not designed for applets or browsers and if you set a header you expect it to be sent over the wire.

Source from HttpUrlConnection:

http://www.docjar.com/html/api/sun/net/www/protocol/http/HttpURLConnection.java.html

146 /*
147 * Restrict setting of request headers through the public api
148 * consistent with JavaScript XMLHttpRequest2 with a few
149 * exceptions. Disallowed headers are silently ignored for
150 * backwards compatibility reasons rather than throwing a
151 * SecurityException. For example, some applets set the
152 * Host header since old JREs did not implement HTTP 1.1.
153 * Additionally, any header starting with Sec- is
154 * disallowed.
155 *
156 * The following headers are allowed for historical reasons:
157 *
158 * Accept-Charset, Accept-Encoding, Cookie, Cookie2, Date,
159 * Referer, TE, User-Agent, headers beginning with Proxy-.
160 *
161 * The following headers are allowed in a limited form:
162 *
163 * Connection: close
164 *
165 * See http://www.w3.org/TR/XMLHttpRequest2.
166 /
167 private static final boolean allowRestrictedHeaders;
168 private static final Set restrictedHeaderSet;
169 private static final String[] restrictedHeaders = {
170 / Restricted by XMLHttpRequest2 /
171 //"Accept-Charset",
172 //"Accept-Encoding",
173 "Access-Control-Request-Headers",
174 "Access-Control-Request-Method",
175 "Connection", / close is allowed */
176 "Content-Length",
177 //"Cookie",
178 //"Cookie2",
179 "Content-Transfer-Encoding",
180 //"Date",
181 //"Expect",
182 "Host",
183 "Keep-Alive",
184 "Origin",
185 // "Referer",
186 // "TE",
187 "Trailer",
188 "Transfer-Encoding",
189 "Upgrade",
190 //"User-Agent",
191 "Via"
192 };

It'd be absolutely smashing if we could remove the dependency on Funulate, and also breaking the transitive dependency on ST3. Thanks!

Given the following annotated method:

    @GET
    @Path("/mystuff/{id}")
    public Response doMyStuff(@PathParam("id") int id) {
        ...
    }

.. a call to /mystuff/1 will not match successfully. Changing the int id to Integer id causes the method to match, but is very unobvious. I assume that is also the case with the other Parameter types (Header etc..)

We have fixed a bug in UriTemplate which was causing the template to match() a path but then blow up during extract() of the PathParams contained within:

A template of {name}/{unused:end$} would match the path /value/end/ but then blow up. This occurs because the match() operation trims the slashes from the front and end of the path, but the extract() didn't do this.

We have fixed this to be consistent in v1.84, but has revealed an inconsistency in how the path parameters are handled (in terms of the values returned) between the first and subsequent PathParams. The change means that @Path("{first}/{second}") matches against /my/uri as first -> my and second -> uri. Previously, first would have NOT had the leading slash dropped (ie. /my).

This does represent a change in behaviour, but we now get more consistent results instead of a bug, as both start and end slashes are dropped. We saw only 2 options and took the one which we considered to be better:

1. Drop both the leading and ending slashes (this is v1.84 behaviour)
2. Drop the ending slash only. Less "breaky", but inconsistent.

Any opinions gratefully received! Check out UriTemplateTest for the cases that we covered.

Hi Dan

For some invalid URIs the ClientHttpHandler throws NullPointerException. For example:

 new ClientHttpHandler(0).handle(Request.get(new Uri("junk")));

ClientHttpHandler depends on the scheme in a URI not being null. This can easily be fixed by using the static Objects.equals on line 107.

Thanks
Sydney

When both the NormaliseUriHandler and the BasePathHandler are used (they are both enabled by default), the BasePathHandler fails to work correctly.

Let's say the BasePath is set to /foo/. The BasePathHandler is meant to remove /foo/ from all requests so you don't have to specify the whole path in the resource -- eg, /foo/bar will be converted to just bar.

The NormaliseUriHandler kicks in beforehand though, and will change any request to /foo/ to be /foo, which obviously doesn't match the BasePath.

This is an edge case, but it's quite annoying for the first request!

Pull Request #1 includes a failing test for this issue.

plz :)

Currently when a request does not hit your resource method, one is often forced to debug the following classes:
BaseHandler -> BindingMatcher -> MatchQuality -> ParameterExtractor

Also the app currently vomits Yadic exceptions when in debug mode in a vain attempt to help you work out what went wrong. This tends to actually be a red herring for most users.

Lastly it's quite easy to write a resource binding that contains a typo (say in a PathParam) which will mean the resource will never match.

To resolve all these issues I suggest we create an explain mode (much like the profile mode) that shows you why every resource did not match.

The UriTemplate.extract method decodes the URI before splitting it into path parameters.

public PathParameters extract(String uri) {
    List<String> values = groupValues(templateRegex.findMatches(UrlEncodedMessage.decode(trimSlashes(uri))).head());
    return pathParameters(names.zip(values));
}

This causes any encoded slashes to be converted to slashes and treated as a path separator. I'm pretty sure it would be safe to split first and then decode each parameter individually. I cloned and tried to give it a go but repo.bodar.com:80 is blocked by the company firewall.