I'm attempting to set up a crossdomain.xml to be served at
{mod_http_fileserver, [{docroot, "/var/www"},
{content_types, [{".xml", "text/xml"}]}]},
and
{5280, ejabberd_http, [
web_admin,
{request_handlers, [{["xmpp-httpbind"],
mod_http_bind},
{[], mod_http_fileserver}
]}
]}
per
However, this causes the xml to download from firefox, rather than being displayed in the browser as does
Any ideas? As a related note, this configuration also disabled the web_admin functionality.
Thanks,
Aaron
(Cross-posted at
The option works for me
If I configure the module without the content_type option, I get:
If I configure some rare type:
I get it as configured:
Regardless of the
Regardless of the content_types setting, I'm getting the following. That's after modifying the cfg file and restarting ejabberd of course.
http://xmpp.example.com:5280/crossdomain.xml
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 323
Server: ejabberd
Last-Modified: Fri, 02 Apr 2010 20:44:19 GMT
default_content_type
I've also tried to set default_content_type. Still coming up as application/octet-stream...
{mod_http_fileserver, [{docroot, "/var/www"},
{content_types, [{".xml", "text/xml"}]},
{default_content_type, "text/xml"}
]},
This is ejabberd v. 2.0.0 by
This is ejabberd v. 2.0.0 by the way.
Old ejabberd version, probably doesn't implement the options
This is ejabberd v. 2.0.0 by the way.
Maybe the module you are running doesn't yet implement those options. Check the ejabberd Guide included in that exact version.
I see that the ticketAllow content types to be configured in ejabberd.cfg was implemented in ejabberd 2.1.0
That was it, thanks badlop!
That was it, thanks badlop!
All settings ignored...
Apparently, any settings I have for content_type has no effect.
Here are the tests I've run:
I put "test.html", "test.png" and "test.blah" files in addition to the crossdomain.xml file in /home/my-user/web (not using /var/www since that's apache's home, even though apache's not installed).
{5280, ejabberd_http, [
web_admin,
{request_handlers, [{["xmpp-httpbind"],
mod_http_bind},
{[], mod_http_fileserver}
]}
]}
and
{mod_http_fileserver, [{docroot, "/home/xomba/web"},
{content_types, [{".xml", "text/xml"}, {".png", "experimental/blah"}, {".blah", "nothing/here"}]},
{default_content_type, "text/xml"}
]},
Headers for each:
crossdomain.xml (Expected text/xml)
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 323
Server: ejabberd
Last-Modified: Fri, 02 Apr 2010 20:44:19 GMT
test.html (Expected either application/octet-stream or text/xml depending on whether default_content_type caught it)
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 8
Server: ejabberd
Last-Modified: Mon, 05 Apr 2010 16:13:09 GMT
test.png (expected experimental/blah)
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 12453
Server: ejabberd
Last-Modified: Mon, 05 Apr 2010 16:15:31 GMT
test.blah (expected nothing/here)
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 11
Server: ejabberd
Last-Modified: Mon, 05 Apr 2010 16:23:54 GMT
Negative tests work as
Negative tests work as expected, serving a 404 when disabled.
Oddly, if I comment out the mod_http_fileserver from modules, but leave the listening port, I now get
HTTP/0.9 200 OK
for them all, regardless of whether a file exists, but 0 bytes of course.
aaronwinborn wrote: {5280,
{5280, ejabberd_http, [
web_admin,
{request_handlers, [{["xmpp-httpbind"],
mod_http_bind},
{[], mod_http_fileserver}
]}
]}
this configuration also disabled the web_admin functionality.
Right, I see that problem too. A solution is to indicate explicitely the webadmin, see as example:
As a test, I just recompiled
As a test, I just recompiled mod_http_fileserver from ejabberd_modules (the 2.0.x version) and swapped that with the version at /usr/lib/ejabberd/ebin/mod_http_fileserver.beam, with no effect on behavior. Frustrating.