bodar / utterlyidle Goto Github PK
View Code? Open in Web Editor NEWAnother REST library for Java based around JSR-311
Home Page: https://github.com/bodar/utterlyidle/wiki/02.-Getting-started
Another REST library for Java based around JSR-311
Home Page: https://github.com/bodar/utterlyidle/wiki/02.-Getting-started
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.
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.
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
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..)
plz :)
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.
It'd be absolutely smashing if we could remove the dependency on Funulate, and also breaking the transitive dependency on ST3. Thanks!
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:
Any opinions gratefully received! Check out UriTemplateTest for the cases that we covered.
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.
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.
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 };
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.