Nexus and artifact MIME types

[Tamas Cservenak]

Hello there,

I am interested in Your opinions about following question:

https://issues.sonatype.org/browse/NEXUS-1347

https://issues.sonatype.org/browse/NEXUS-2189

So, here is a brief explanation how Nexus "decides" what is the content type (MIME type) for given file. In short, it don't :)

Nexus _never_ overrules what it gets from remote peer (either, when proxing, from remote HTTP server, or when deploying, from uploading client like Maven CLI). The content type got from remote peer is simply stored as item attribute, and whenever it is requested, the given MIME type will be used.

But. As you see in 2nd issue, there is some mishap with _generated_ (merged, aggregated) items -- which is probably a bug and will be fixed. But, in 1st issue, the situation _might_ be more complicated.

Consider following scenario: you are proxying three M2 reposes, two published by Mick Jagger, and a third one published by Bowie (the David).

Mick preferred MS software, so he uses IIS to publish his 1st maven repo. But since current depression, he switched, and the 2nd repo is published from a Linux machine using Apache HTTPD.

David, oddball as he is, prefers Mac and nginx.

So, who _guarantees_ that XMLs, JARs, ZIPs and who knows what, served from those machines will have the _same_ MIME type? The rfc? Nah.

The 1st issue says "Nexus serving up some files - JARs, .pom.md5, other things that are not appropriate - with Content-Type: application/xml". Just to clear up: this means that some remote peer of Nexus is serving those as "application/xml" (badly configed HTTP server probably, or some nasty deployer). The reason why we resolved this as "Cannot Reproduce" is probably since we never hit the broken server in question.

Moreover, "smart clients" like browsers and wget mentioned in 1st issue is able and usually _does_ correct the MIME type on-the-fly and overrules if it finds the sent MIME type "wrong" (whatever it means).

---

So, where I started to think about this issue, is that maybe Nexus (actually given repository class, like M2, P2, OBR, etc) should be considered as "authoritative source" about this, and in contrary to current case, Nexus should _always_ override the content class of stored (uploaded in case of hosted, cached in case of proxied) reposes?

Or, Nexus should be less invasive and offer some "maintenance task" to fix item attributes with improper MIME types? (Note: this will not fix the bad mime type if the file requested is also proxied in that very moment).

Ideas? Opinions?

~t~

[Alin Dreghiciu]

Why not let Nexus admin decide? Allow him to decide if he wants to overwrite the mime-type per repository. And he could do that just in time or via a maintenance task. 

Also, http://www.medsea.eu/mime-util/index.html could be of help if you plan to implement this. I was planning to use it in Pax Web.

On Tue, Jul 21, 2009 at 12:32 AM, Tamas Cservenak <cstamas@...> wrote:

Hello there,

I am interested in Your opinions about following question:

https://issues.sonatype.org/browse/NEXUS-1347

https://issues.sonatype.org/browse/NEXUS-2189

So, here is a brief explanation how Nexus "decides" what is the content type (MIME type) for given file. In short, it don't :)

Nexus _never_ overrules what it gets from remote peer (either, when proxing, from remote HTTP server, or when deploying, from uploading client like Maven CLI). The content type got from remote peer is simply stored as item attribute, and whenever it is requested, the given MIME type will be used.

But. As you see in 2nd issue, there is some mishap with _generated_ (merged, aggregated) items -- which is probably a bug and will be fixed. But, in 1st issue, the situation _might_ be more complicated.

Consider following scenario: you are proxying three M2 reposes, two published by Mick Jagger, and a third one published by Bowie (the David).

Mick preferred MS software, so he uses IIS to publish his 1st maven repo. But since current depression, he switched, and the 2nd repo is published from a Linux machine using Apache HTTPD.

David, oddball as he is, prefers Mac and nginx.

So, who _guarantees_ that XMLs, JARs, ZIPs and who knows what, served from those machines will have the _same_ MIME type? The rfc? Nah.

The 1st issue says "Nexus serving up some files - JARs, .pom.md5, other things that are not appropriate - with Content-Type: application/xml". Just to clear up: this means that some remote peer of Nexus is serving those as "application/xml" (badly configed HTTP server probably, or some nasty deployer). The reason why we resolved this as "Cannot Reproduce" is probably since we never hit the broken server in question.

Moreover, "smart clients" like browsers and wget mentioned in 1st issue is able and usually _does_ correct the MIME type on-the-fly and overrules if it finds the sent MIME type "wrong" (whatever it means).

---

So, where I started to think about this issue, is that maybe Nexus (actually given repository class, like M2, P2, OBR, etc) should be considered as "authoritative source" about this, and in contrary to current case, Nexus should _always_ override the content class of stored (uploaded in case of hosted, cached in case of proxied) reposes?

Or, Nexus should be less invasive and offer some "maintenance task" to fix item attributes with improper MIME types? (Note: this will not fix the bad mime type if the file requested is also proxied in that very moment).

Ideas? Opinions?

~t~

--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.