tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun Jamwal <Arun.Jam...@eng.sun.com>
Subject Re: vote please
Date Fri, 22 Oct 1999 18:01:55 GMT

Ok, I am going to change the Tomcat product tests to expect
    /servlet -> 404
    /servlet/ -> 403

Thanks,
Arun.


James Todd wrote:

> with the goal in mind of getting the tests passing
> again and taking into account all that i've read
> yet choosing not to dive into the details (http
> spec interpretations and the like) for the moment
> why don't we configure the existing tests to follow
> what apache does:
>
>         /servlet -> 404
>         /servlet/ -> 403
>
> the current tests are doing string comparisons and
> are not capabible, as i recall, of checking integer
> comparisons.
>
> to make this even simplier, we could just go with
> a 404 for the time being for both types or requests
> and be done with it for the moment.
>
> something changed. we need to discuss 1) either rolling
> back the changes which the tests righfully picked up or
> 2) adjusting the tests to account for the change.
>
> - james
>
> Costin.Manolache@eng.sun.com wrote:
> >
> > Since HTTP doesn't mandate one or another, I don't
> > think it matters too much if it's 404 or 403.
> >
> > In fact - the message is supposed to show what failed - if
> > the code is rejecting the url from security reasons -
> > let it say so, if DefaultServlet can't find "" - let it be
> > not found.
> >
> > In any case, the "test" can only verify just if code>400.
> > We can't change or vote on how to interpret HTTP specs -
> > and adding a test will mean our ( democratic ) interpretation
> > is the "right" one, and anyone should do the same.
> >
> > My vote will be to return the error that shouw what failed.
> >
> > In the worst case, we should use the same error code Apache is
> > returning, and not invent another interpretation:
> >
> > for /cgi-bin  404
> > for /cgi-bin/  403
> > ( in fact the error code in Apache is generated by the handler module,
> > not by arbirary interpretation - /cgi-bin/ is rejected just because
> > cgi-bin is configured to refuse to serve static files in that dir, while
> > /cgi-bin is just not found)
> >
> > Costin
> >
> > > ok ... we've got 2 for 404 and 2 for 403.
> > >
> > > i can lean one way or the other and will
> > > shift to 404 (if changing my vote mid-stream
> > > doesn't cause anyone grief) in order to
> > > ratify the 404 in order to get the tests
> > > passing again. is this fair?
> > >
> > > if someone wants to discuss this further
> > > please register a -1 and we'll work this
> > > issue a bit more.
> > >
> > > that said, i'm still curious as to what has
> > > changed to cause the reported error codes
> > > to shift. i'll see if i can dig into this.
> > >
> > > hope this helps,
> > >
> > > - james
> > >
> > > Hans Bergsten wrote:
> > > >
> > > > James Todd wrote:
> > > > > [...]
> > > > > the issue at hand is what should the http return code
> > > > > be for a "/servlet" and "/servlet/", effectively a
> > > > > directory listing, request be:
> > > > >
> > > > >         404 - not found
> > > > >         403 - forbidden
> > > > >
> > > > > i don't believe the servlet 2.2 spec is explicit to this
> > > > > detail for this matter ... but i could be wrong.
> > > > >
> > > > > given that arun put this item on the table and as such
> > > > > is indirectly asking for a vote i'll register:
> > > > >
> > > > >         +1 for 403 - forbidden
> > > > >
> > > > > with an understanding that there may be good merits for
> > > > > a 404 to which i'm open.
> > > >
> > > > My vote is
> > > >
> > > >  +1 for 404 - not found
> > > >
> > > > I feel this is closest to the definitions in the HTTP spec, see below,
> > > > since the request can be seen as a request for a servlet named "" (this
> > > > is a logical path, no "directory" exist).
> > > >
> > > > Another reason for using 404 is pure laziness; I know that's what our
> > > > servlet containers return and I assume others may as well since it's
> > > > what the reference implementation used to return.
> > > >
> > > > 10.4.4 403 Forbidden
> > > >
> > > >    The server understood the request, but is refusing to fulfill it.
> > > >    Authorization will not help and the request SHOULD NOT be repeated.
> > > >    If the request method was not HEAD and the server wishes to make
> > > >    public why the request has not been fulfilled, it SHOULD describe the
> > > >    reason for the refusal in the entity. This status code is commonly
> > > >    used when the server does not wish to reveal exactly why the request
> > > >    has been refused, or when no other response is applicable.
> > > >
> > > > 10.4.5 404 Not Found
> > > >
> > > >    The server has not found anything matching the Request-URI. No
> > > >    indication is given of whether the condition is temporary or
> > > >    permanent.
> > > >
> > > >    If the server does not wish to make this information available to the
> > > >    client, the status code 403 (Forbidden) can be used instead. The 410
> > > >    (Gone) status code SHOULD be used if the server knows, through some
> > > >    internally configurable mechanism, that an old resource is
> > > >    permanently unavailable and has no forwarding address.
> > > >
> > > > Hans
> > > > --
> > > > Hans Bergsten           hans@gefionsoftware.com
> > > > Gefion Software         http://www.gefionsoftware.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message