that all makes sense
-M
On Thu, Aug 15, 2013 at 4:25 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
Sounds reasonable. Let's call it enablement of more strict
clients in next
iteration. Meanwhile, I think specs should be updated to say clients
require to
set Content-Type to "application/json", do you agree?
On Thu, 15 Aug 2013 16:21:37 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
> This works fine (see: no payload):
> curl -3 -v -b cookies.txt -c cookies.txt -v -H "Accept: application/json"
> -H "Content-type: application/json" -X DELETE
>
https://https-pushee.rhcloud.com/rest/applications/e952017a-9d6c-4716-880...
>
>
> Here I do get a 415:
> curl -3 -v -b cookies.txt -c cookies.txt -v -H "Accept: application/json"
> -X DELETE
>
https://https-pushee.rhcloud.com/rest/applications/e952017a-9d6c-4716-880...
>
>
> Let's fix that for the next iteration
>
>
>
>
>
> On Thu, Aug 15, 2013 at 4:17 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
>
> > Yes, there should be no payload, hence no Content-Type header for
DELETE.
> > Some
> > clients ignore Content-Type if they construct DELETE requests, which is
> > apparently not curl case.
> >
> > I've updated the JIRA with more details. The endpoint I'm speaking
about
> > is /rest/applications/${pushAppId}, but most of @DELETE endpoints are
> > affected
> > by requiring content type or content type and payload.
> >
> >
> > On Thu, 15 Aug 2013 09:04:00 -0500
> > Kris Borchers <kris(a)redhat.com> wrote:
> >
> > >
> > > On Aug 15, 2013, at 9:01 AM, Matthias Wessendorf
<matzew(a)apache.org>
> > wrote:
> > >
> > > > Kris - I guess this is the 'problem':
> > > >
> > > >
> >
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m...
> > > >
> > > > I always did CURL DELETE, but I NEVER gave payload with it ....
> > but.......
> > > > (my bad?) I did always include this:
> > > >
> > > > curl -v -b cookies.txt -c cookies.txt -v -H "Accept:
application/json"
> > -H
> > > > "Content-type: application/json" -X DELETE
> > >
> > > Oh, yeah if you're referring to the Content-type that should not be
> > required
> > > for DELETE
> > > > .........
> > > >
> > > >
> > > > On Thu, Aug 15, 2013 at 3:59 PM, Kris Borchers
<kris(a)redhat.com>
> > wrote:
> > > > Yeah, I assumed this was an actual problem but don't see any
reference
> > to
> > > > our spec or code where we require a body for DELETE. Karel, can
you add
> > > > that to the JIRA or at least clarify what actual issue you have run
> > into?
> > > >
> > > > On Aug 15, 2013, at 8:54 AM, Matthias Wessendorf <
matzew(a)apache.org>
> > wrote:
> > > >
> > > >> Hello,
> > > >>
> > > >> We have "@Delete APIs" that are used by the
devices/client (for
> > > >> unregistrations), but that does not require any data: ==>
> > > >>
> >
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m...
> > > >> It only reads the /token from the URL and the headers (for
basic)
> > > >>
> > > >> We have other endpoints that are used by the AdminUI, e.g.
> > > >>
> >
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m...
> > > >> That also really just reads out of the URL .
> > > >>
> > > >>
> > > >> I also don't see where the spec, e.g.:
> > > >>
> >
http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplication/
> > > >> talk about JSON payload required
> > > >>
> > > >>
> > > >>
> > > >> -Matthias
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 15, 2013 at 3:35 PM, Karel Piwko
<kpiwko(a)redhat.com>
> > wrote:
> > > >> Hi All,
> > > >>
> > > >> I think that DELETE requests in Push Server do not conform to
> > HTTP/REST
> > > >> specifications because they require request body. More details
here:
> > > >>
> > > >>
https://issues.jboss.org/browse/AGPUSH-298
> > > >>
> > > >> Should we change them in 0.8.0 release?
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Karel
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev(a)lists.jboss.org
> > > >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matthias Wessendorf
> > > >>
> > > >> blog:
http://matthiaswessendorf.wordpress.com/
> > > >> sessions:
http://www.slideshare.net/mwessendorf
> > > >> twitter:
http://twitter.com/mwessendorf
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev(a)lists.jboss.org
> > > >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev(a)lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog:
http://matthiaswessendorf.wordpress.com/
> > > > sessions:
http://www.slideshare.net/mwessendorf
> > > > twitter:
http://twitter.com/mwessendorf
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev(a)lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev