Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

Agreed on discouraging (or at least not actively encouraging) the use of JSONP. Everything I've read on it has started with big "Do not try this at home!" warnings. I also very strongly agree on built-in support for CORS, especially elements of DRF getting more tightly integrated into the core. I

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

JSONP is essentially a browser hack. There have been security issues raised around it, and we I don't believe we should encourage its usage by including it in Django core. (If anything we *might?* want to consider CORS for built-in support at some point.) I'd agree with Florian here - I'd rather

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

On Saturday, April 16, 2016 at 4:06:04 AM UTC+2, brigh...@gmail.com wrote: > > JsonpResponse isn't needed for most use cases. But is needed for some use > cases. > Like which? I think this should better live outside of Django. -- You received this message because you are subscribed to the

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

Would it be better to add an optional parameter to the constructor of JsonResponse instead of a new subclass? On 16 Apr 2016 12:06 PM, wrote: > Django 1.7 realease JsonResponse subclass of HttpResponse helps easily > create JSON-encoded responses. > > As discussed in

JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

Django 1.7 realease JsonResponse subclass of HttpResponse helps easily create JSON-encoded responses. As discussed in https://code.djangoproject.com/ticket/17942#comment:6 - Trying to support JSONP callbacks would require to somehow allow Cross-origin resource sharing. I would say it's