jakarta-watchdog-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: Testing SRV 4.7 (SSL Attributes)
Date Wed, 25 Sep 2002 05:05:34 GMT
Comments inline ...
On Tuesday 24 September 2002 11:21 pm, Ryan Lubke wrote:
> Hi Jason,
>
> Comments inline....
>
> Jason Hunter wrote:
> >Thanks for the fast response, Ryan.
> >
> >Here's how I read the spec.  Simple servlet containers (outside J2EE)
> >aren't required to support SSL/HTTPS.  However *if a container does
> >choose to support SSL/HTTPS* then they're required to expose those
> >attributes.
> >
> >Per SRV.4.7: "If a request has been transmitted over a secure protocol,
> >such as HTTPS, this information must be exposed via the isSecure method
> >of the ServletRequest interface. The web container must expose the
> >following attributes to the servlet programmer: ..."
> >
> >So the rule for implementors is either (a) don't do SSL or (b) do it
> >correctly.  I don't think it's appropriate to assume that since
> >something is optional then we shouldn't test that when present the item
> >behaves as it should
>
> I don't disagree that when using SSL, there are strict requirements that
> must be followed, but as far as the TCK goes the functionality is
> optional per the spec and won't be tested (unless there is a shift in
> testing philosophy).
>

It sounds like there is a desparate need to change the testing philosophy. As 
it stands a container that provides a non-conforming implementation of an 
optional feature is incorrectly labled as conforming. That's bad.

If a container does not support an optional section of a test, it's a PASS for 
the section, but optional does not equal do not test.

> >.
> >
> >In fact, I think it's entirely within Watchdog's (and the TCK's) current
> >goals to ensure that the spec is followed.  Otherwise anything optional
> >in a JSR is unlikely to work when present.
>
> I think it would be easier for Watchdog at this point in time as it's
> not restricted by
> being an official TCK.
>

So it can be worked on, and the point of including it in the TCK can be argued 
later.

> >Here's pseudocode:
> >
> >1) Try to connect using HTTPS
> >2) If fails, return OK
> >3) If succeeds, check attributes
> >4) If attributes correct, return OK
> >5) If attributes incorrect, return FAIL
> >
> >In reality the it may need to be the docs that say, "If you support
> >HTTPS then run this test to make sure you support it fully" in order to
> >satisfy lines 1 and 2.
>
> I agree that it should be documented.  I think if the user is making a
> conscience
> decision to test SSL, then step 2 should probably be "If fails, return
> FAIL".
>

I think Jason has the right approach. Check if SSL is present. If it's not, 
the section PASSes. Actually, it should be UNSUPPORTED, which is a pass for 
an optional feature. 

> >Thoughts, Ryan?
> >
> >-jh-


--
To unsubscribe, e-mail:   <mailto:watchdog-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:watchdog-dev-help@jakarta.apache.org>


Mime
View raw message