[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter

[Daniel Bevenius]

>What do you mean by that regex?
That the JAXRS implementation should not disallow as '/' in the path.

>The problem is simply the “%2F” in the token (which is an URLencoded
simplepush url) and it’s being revoked long before it hits the RestEasy
(which does the routing according to what’s in the @Path).
I guess I don't understand why this would be revoked by anything before it
hits the JAXRS implementation, but if that is the case you are right and
adding this would not help.






On 25 July 2014 12:25, Tadeas Kriz <tkriz at redhat.com> wrote:

>
> —
> Tadeas Kriz
>
> On 25 Jul 2014, at 11:04 am, Daniel Bevenius <daniel.bevenius at gmail.com>
> wrote:
>
> >5. don’t use the url as a deviceToken (might not comply with Mozzila’s
> SimplePush specs)
> The deviceToken is an UPS concept and there is nothing in the SimplePush
> spec which is violated in this case.
>
> I thought that deviceTokens were changed from a generated value to the URL
> just to comply with Mozzila’s SimplePush specs. Matzew, why was the
> generated token removed then?
>
> I'm not sure about what the best option is for UPS thought. Would a regex
> in for the @Path annotation work perhaps, something like:
>
> @DELETE
> @Path("{token, .+}")
> public Response unregisterInstallations(
>
>
> What do you mean by that regex? The problem is simply the “%2F” in the
> token (which is an URLencoded simplepush url) and it’s being revoked long
> before it hits the RestEasy (which does the routing according to what’s in
> the @Path).
>
>
> On 25 July 2014 10:32, Tadeas Kriz <tkriz at redhat.com> wrote:
>
>>
>> —
>> Tadeas Kriz
>>
>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko at redhat.com> wrote:
>>
>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>> >>
>> >> It should not. For hibernate, it’s just a string like any other.
>> >> The problem might be in the configuration of JAX.RS/RestEasy
>> <http://jax.rs/RestEasy>. If
>> >> I’ll have some time today evening, I’ll try to fix it, it should
>> >> be an easy fix.
>> >
>> > Last famous words? ;-)
>> >
>>
>> I shall never say “an easy fix” again.
>>
>> > But I agree. Everything is string and URL encode should happen on
>> > client while server should automatically decode and work always with
>> > just decoded string. If we need to encode twice, something is wrong.
>> >
>>
>> Anyway, the 400 Bad request response is made by the tomcat itself,
>> disallowing the use of %2F as a path parameter. This will probably apply on
>> other web containers.
>>
>> Possible solutions with their disadvantages:
>>
>> 1. well-documented double-encoding of the URL (might be confusing)
>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as
>> every other call would still use @PathParam)
>> 3. allow @QueryParam (again, breaks the api consistence, but only for the
>> SimplePush)
>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode)
>> 5. don’t use the url as a deviceToken (might not comply with Mozzila’s
>> SimplePush specs)
>>
>> What do you think guys?
>>
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/5f4158c5/attachment-0001.html