Re: Testing SRV 4.7 (SSL Attributes)

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 metho=
d
> >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 ite=
m
> >behaves as it should
>
> I don't disagree that when using SSL, there are strict requirements tha=
t
> 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=
=2E As=20
it stands a container that provides a non-conforming implementation of an=
=20
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 PAS=
S for=20
the section, but optional does not equal do not test.

> >.
> >
> >In fact, I think it's entirely within Watchdog's (and the TCK's) curre=
nt
> >goals to ensure that the spec is followed.  Otherwise anything optiona=
l
> >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 a=
rgued=20
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 t=
o
> >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 no=
t,=20
the section PASSes. Actually, it should be UNSUPPORTED, which is a pass f=
or=20
an optional feature.=20

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