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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
