[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Paperclips-discuss] SocketServer issues
From: |
Nic Ferrier |
Subject: |
Re: [Paperclips-discuss] SocketServer issues |
Date: |
Tue, 26 Jun 2001 15:40:36 +0100 |
>>> "Christopher K. St. John" <address@hidden> 26-Jun-01
2:50:30 PM >>>
Hmmm. Ok, I see what you mean, but what I
meant was that the file server WWW itself is a
servlet, so that additional mime-types could be
set in WWW's DD. Well, it doesn't have
a DD now, but it could.
I don't really understand what you mean by this.
WWW is (usually) Paperclips default servlet, the servlet that matches
all non-matched request URIs.
As such it should take the content type registry from the servlet
context, just like all the other servlets.
The servlet context's registry can come from the DD. But it doesn't
*nned* to (as long as you can override it like that).
That admittedly doesn't address the issue for
where to get the basic set of mappings for
non-WWW webapps, but it's not like webapps
could ever assume that any mappings were available.
They could if they delpoyed them in the DD.
URLConnection.getContentType() can legally return
null for just about everything, and
ServletContext.getMimeType() is under user control
anyway.
What I was suggesting earlier is that there should be one
authoritative source for mime types, either the servletcontext method
or the PURLH. Whichever it is all the content-type registry query
methods in Paperclips should consult it.
eg: the authoritative source is servletcontext.getMimeType() then the
FURLH (the file based PURLH) would have a method like this:
public String getContentType()
{
return this.servletContext.getMimeType(this.fileName);
}
Nic said:
I've just recompiled socketserver and Paperclips
and had no problem.
cks said:
Yeah, 'cause you just checked in a fix :-P
Ho Ho! I didn't mean to... honest!
BTW if you register on savannah I'll add you to the Paperclips
developer list. You can make these changes directly if you want.
Nic