How to set mime-type in JApplicationWeb

[Andreas Tasch]

Hi,

what is the correct platform way to set the header information. Inside my JApplicationWeb app i want to set the mime type to something other than 'text/xml'.

I tried JDocument, JResponse and $this->setHeader nothing works. Only if I do a $this->mimeType('my-mime-type'); But I assume manipulating a class var directly instead setter method is not the way to go and may brake in future.

Here you can see an example:
http://pastebin.com/VWJEJwgd

Thanks,
ndee

[Andreas Tasch]

This line seems to overwrite the header set by $this->setHeader() with the initial "text/html" value?
https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/application/web.php#L417

[Michael Babker]

Since $this->mimeType is a public variable, you should be free to set that to what you need it to be.  When the response is sent in that method, that's when the headers are built it looks like.

[Will Daniels]

I have always used JDocument::setMimeEncoding [1]

But strictly speaking, that is a misnomer because it's actually setting the
Content-Type header not the Content-Transfer-Encoding header as implied by
"encoding". It should be setMimeType.

-Will

https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/document/document.php#L803

> !DSPAM:4fbf47ac11383571150820!
>

[Will Daniels]

Example usage in an old CMS system plugin of mine:

https://github.com/wdaniels/joomla-xhtml-headers/blob/master/xhtml.php

I assume things work much the same still, though I haven't had time to play
around making any apps using just the Platform yet.

Hope this helps.

-Will

> !DSPAM:4fbf77df11381723048547!
>
>

[Andreas Tasch]

Hi Will and Michael,

thank you for your help. 

Will in your plugin you use JDocument->setMimeType() to set the mime-type. As you can see on my pastebin example above, I tried that too. JDocument sets the header properly but on output JApplicationWeb seems to ignore it and uses instead only the JApplicationWeb->mimeType variable.

Even if I try to set the header with JApplicationWeb->setHeaders() they get actually set but the mime-type is ignored and replaced/overwritten by the JApplicationWeb->mimeType variable. 

Short, neither JDocument nor JApplicationWeb->setHeaders() are able to set the mime-type because only the public var JApplicationWeb->mimeType is taken into account.

Here the above pastebin example with some testoutput. Just run the file and you will see that $this->setHeaders() and $document->setMimeEncoding() have NO effect on the mime-type output. Only if you uncomment the direct change of $this->mimeType you will get the correct mime-type.

http://pastebin.com/CQPqx2eV

My question is, do I miss something or why do setHeaders() or $doc->setMimeType not get recognized or taken into account by JApplicationWeb?

Please take also a look in second post mentioned line, where JApplicationWeb renders the document and gets the mime-type directly from its mimeType variable and does not check JDocument or its own headers if the mime-type got set.

https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/application/web.php#L417

Do you guys think this is a bug or expected behaviour?

Thanks!

2012/5/25 Will Daniels <ma...@willdaniels.co.uk>

[Elin Waring]

It looks to me like that line is missing the replacement flag so it is defaulting to false and not replacing. 
https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/application/web.php#L639

Elin

[Andreas Tasch]

Hi Elin,

please take a look at my example, line 45:
http://pastebin.com/CQPqx2eV

I used the override switch, or did I miss something, or am I using it the wrong way?

As mentioned I think the problem is that the values set by setHeader() are set but not taken into account in response() function. That's why I mentioned line 417 in JApplicationWeb:
https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/application/web.php#L417
(other headers are handled correctly but mime-type is set by class variable mimeType, and mime-type set by setHeaders() is not taken into account?)

2012/5/30 Elin Waring <elin....@gmail.com>

[Elin Waring]

I know you are using the flag, what I'm questioning is why 417 doesn't use the replacement flag which in the case of mime type perhaps should default to true.

Elin

[Andreas Tasch]

Hi Elin,

sorry my fault. The flag is imho working but the problem is that $this->mimeType is used as content-type no matter what is set by setHeaders (see line 417 in JApplicationWeb). Imo the problem is that setHeaders() does not update $this->mimeType. So a possible solution is to add a few lines of code to setHeaders() to update mimeType variable:

https://github.com/ndeet/joomla-platform/commit/f3c53e719cd7bab8657cad991a86c1868da79d75

However, JDocument->setMimeType() is still not working, have to figure that one out too. Seems that it is passed to JResponse - dunno but JResponse is not overwriting the header output. 

2012/5/30 Elin Waring <elin....@gmail.com>

[Andreas Tasch]

Hi anybody,

please let me know if my proposed patch fixes the problem and I should open a tracker item on github or make a pull request on this issue. Here is my suggestion:

https://github.com/ndeet/joomla-platform/commit/f3c53e719cd7bab8657cad991a86c1868da79d75 

The JDocument issue is not yet resolved as I had no time yet too look deeper into the issue. In general terms, shouldn't JDocument::setMimeEncoding etc. delegate the header stuff to JApplicationWeb? Is there a good reason that JDocument and JApplicationWeb does the same thing differently? 

Am Freitag, 25. Mai 2012 09:31:30 UTC+2 schrieb Andreas Tasch:

[Sam Moffatt]

JApplicationWeb is a new class which is a mix of various previous
classes and a re-think about how a Joomla! web application works.
JDocument is a much older class (easily coming up on it's 5th
birthday) and was designed with the legacy JApplication class.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Andreas Tasch]

Hi Sam,

thanks for clarification. So, the JDocument->setMimeEncoding() should actually work and change the mime type output. But on my previous code snipped I was not able to do that. Therefore I started this thread. 

First, the new (JApplicationWeb) way is to use class variable mimeType or the function setHeaders() - the latter does not seem to work therefore my try to fix it and the question if anybody can confirm this as bug.

Second, JDocument->setMimeEncoding() does not work either or I use it the wrong way (see code snipped). Would be great if anybody can confirm if this is also a bug (then I can see if I can fix it) or show me the right way to use it (in case I use it the wrong way).

Thanks.

2012/6/13 Sam Moffatt <pas...@gmail.com>

[Elin Waring]

I was going to say that you should write a test for the bug but respond() is one of the small number of places in JApplicationWeb that doesn't have any test at all so you would need to write the whole thing. But setHeader is covered and that's where you are proposing code ... so if you wrote a test specific test for mime/type and that failed we would definitely know there is a problem there.  I would think it would be better to actually fix the problem with setHeader if there is one than to write in such a specific work around. Why would it be that setHeader works for everything but mime/type? ... it seems a bit odd but there have been much stranger things. 

Elin

[Sam Moffatt]

No, I don't think JDocument::setMimeEncoding() should likely work with
the new classes as it was built for a differently structured class and
application configuration (the JResponse class). It should likely
continue to do this at least in the short term otherwise the CMS will
break. As I noted, JDocument was built for a different version of
JApplication. JDocument's future is an interesting question however I
really don't think it's use coupled with the new JApplicationWeb class
is intended or advised (though obviously not impossible, there is just
an overlap between what it expects and reality for your new
application).

JApplicationWeb::setHeaders() is working though I think if you look
carefully you will find that effectively what you're instructing the
app to do is send two content type headers. PHP if it isn't passing
that along will be picking one of them and sending it. The intended
behaviour is that you set the variable in the application and it is
handled for you.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

On Thu, Jun 14, 2012 at 9:47 PM, Sam Moffatt <pas...@gmail.com> wrote:

JDocument's future is an interesting question however I
really don't think it's use coupled with the new JApplicationWeb class
is intended or advised (though obviously not impossible, there is just
an overlap between what it expects and reality for your new
application).

But, JDocument is coupled with JApplicationWeb. ?

https://github.com/joomla/joomla-platform/commit/b73345998452b8aebc05aff4ab83dac494b8ecdf#L0L674

 

 

The intended
behaviour is that you set the variable in the application and it is
handled for you.

That's all I hear him asking -- was that the intention, or are the getter/setters accidentally missing (and therefore, he found a bug)? 

[Sam Moffatt]

On Thu, Jun 14, 2012 at 9:23 PM, Amy Stephen <amyst...@gmail.com> wrote:
>> JDocument's future is an interesting question however I
>> really don't think it's use coupled with the new JApplicationWeb class
>> is intended or advised (though obviously not impossible, there is just
>> an overlap between what it expects and reality for your new
>> application).
>
>
> But, JDocument is coupled with JApplicationWeb. ?

You can use it, I just don't feel it's advised. As noted there is an
overlap and there are things JDocument does that JApplicationWeb
doesn't and don't exist elsewhere. As I noted, it's an interesting
question where we take this because having two classes doing similar
things causes confusion hence this discussion.

>> The intended
>> behaviour is that you set the variable in the application and it is
>> handled for you.
>
>
> That's all I hear him asking -- was that the intention, or are the
> getter/setters accidentally missing (and therefore, he found a bug)?

It's a public variable. Why do you need getters and setters for a
public variable? And is the statement somehow unclear? I'm confused!

[Andreas Tasch]

Hi thanks for your answers and clarification!

Regarding $mimeType as public var. It is ok, I just have the impression that in changing a public var does not feel right. Imho content-type is releated to PHP's header() function (see http://www.php.net/manual/en/function.header.php). Therefore my impression is that setHeader() should handle it. Maybe I'm wrong and content-type/mime-type is not related to http-headers? - would be great to hear your views on this.

JDocument. Does not the CMS rely heavily rely on JDocument? All code examples I found in manipulating the header (prior to joomla-platform birth) is related to JDocument. So if extensions or even the CMS use JDocument to set mime-type it will not work anymore? What about view.xml.php views will it fail (unfortunately I had no time left yet to check this more deeply). Is there a b/c issue if JDocument is not able to overwrite the headers (or maybe it should be refactored to use JApplicationWeb->setHeader()?

Thank you all for participating.

2012/6/15 Sam Moffatt <pas...@gmail.com>