[OPEN] [#522] [1.6] Content-Type in DirectEvent response

[moldeveloper]

I'm using version 1.6 (when my svn access will be activated I'll start the transition to 1.7), and I'm having a problem due to the content type of direct events' response. The problem is the same as reported here http://forums.ext.net/showthread.php...Type-Mis-Match.
I'm using a proxy that needs to modify html pages, and it modifies responses containing a json string because the content type is set to "text/html". Direct methods seem to work correctly, as the content type is set to "application/json".
Is there some configuration/workaround? I could write an HTTP filter to modify the response, but it would not be the best way.

[Daniil]

Hi @moldeveloper,

I am not sure we can change "text/html".

I'm using a proxy that needs to modify html pages, and it modifies responses containing a json string because the content type is set to "text/html".

There is an "X-Ext.Net" ("X-Ext-Net" in SVN sources) header we send with each Ext.NET AJAX request. If you can analyze it and decide the response should be changed or no.

Direct methods seem to work correctly, as the content type is set to "application/json".

I guess only with "json: true" setting?

[moldeveloper]

I am not sure we can change "text/html".

Why? I think it's a bug, the content in this case is never an HTML stream but a JSON serialization.

There is an "X-Ext.Net" ("X-Ext-Net" in SVN sources) header we send with each Ext.NET AJAX request. If you can analyze it and decide the response should be changed or no.

Ok, I'm going to try, I hope not to put excessive overhead on every request.

I guess only with "json: true" setting?

Yes. I removed the setting but I got a server error 500 (don't know why).

[Daniil]

Well, it is hardly a bug. At least, it is very controversial.

First of all, we deal with a DirectEvent's response on client side and parse it flawlessly.

Moreover, a response of a DirectEvent might be a real "text/html" in the case of downloading. It can be just a piece of text, not a JSON, if it is a DirectEvent for a <Loader> with Mode="Scripts" or "Html". So, we cannot set "application/json" for any DirectEvent. Respectively, it is not a way to distinguish a DirectEvent from other requests. As I said earlier, there is a label of Ext.NET DirectEvent in the headers which you can analyze to distinguish a DirectEvent request from others.

One more point, that legacy browsers might have problems with "application/json". The legacy browsers are still supported.
http://www.entwicklungsgedanken.de/2...plicationjson/

Please share what you think about the thoughts above.

[moldeveloper]

Hi Daniil,

I agree that not every DirectEvent response should use "application/json". But I think that when (and only when) the stream is a JSON serialization, the Content-Type should match. As for old browser compatibility, you could add a configuration flag or check server-side the browser version and act accordingly.
I looked the sources, is it possible to know when JSON is used inside the Flush() method of the AjaxRequestFilter class?
I made an HttpModule to change the Content-Type and it seems to work, but I would like not to use it.

[Daniil]

Thank you for the suggestion. We will re-consider that for Ext.NET v3.
https://github.com/extnet/Ext.NET/issues/522