On Wednesday Apr 21, 1999, Carlos Amengual wrote:
> Howard Melman escribi�:
> >
> > On Wednesday Apr 21, 1999, Carlos Amengual wrote:
> >
> > > Precisely, I wrote Sun to clarify this point some days ago
> > > but haven't received a response yet. I have looked at
> > > various RFCs (1867, 2068, 2183, 2184, 2388) but found
> > > nothing of interest there, though I admit that due to the
> > > speed reading these documents it is perfectly possible
> > > that I missed something.
> >
> > Since servlets are supposed to work for more than just
> > HTTP/HTML I don't think those documents could possibly
> > contain a valid answer.
>
> I don't think that servlets are for more than HTTP or any
> request-response relative, but in any case these documents
> not only talk about HTTP, but of Internet Media Types.
Well it's the reason the API is split into the generic
serlvet class and the http specific ones. See page v of the
preface of version 2.1a.
My point is that even if the underlying protocol treats
things one way, there is no requirement that the API treat
it the same. There is no normative statement in the API
spec (that I found) which makes any kind of required
connection.
E.g., given the following HTTP request headers:
1. Allow:
2. Allow: foo
3. Allow: GET
4.
Where 4 indicates that the header is not found in the
request at all and I intend the difference between 2 and 3
is that one is a legal value and one is not . What should
getParameter("Allow") return? The servlet spec could be
defined to do anything it wants, here are some
possibilities:
a. return null
b. return ""
c. return the value found
d. throw an exception like IllegalArgumentException
There are of course others. The spec could easily require
a or b for 1 or 4. It could require d for 2. Should the
API indicate a difference between 1 and 4? I'm not sure.
I'd really like the spec (and other of sun's java specs) to
adopt the terminology of RFC 2119 or it's equivalent.
Without rigorous specification it's still possible to define
semanticly vague interfaces in java (e.g., return null or an
empty string). As long as people are doing different
implementations (competition is good) there will be problems
writing portable applications. I hope this is something
that no one wants.
Sorry for going off on the deep end on this, it's just a
sore point of mine.
Howard
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
