[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Http test server
|
Hi Pascal,
Pascal Rapicault wrote:
> 1) Identifying what server 'misbehavior' we/others wish to test against
I think we need to test misbehavior as well as regular behavior. On
the misbehavior side, the two cases that comes to mind are:
- Server timing out, so we can verify the responsiveness of
cancellation. Variants where bytes have already been transfered, or
not transfered
- Server never timing out
- Server never sending anything back
- Servers returning an OK status despite having only returned a
partial sets of bytes
I think this is fine.
As for the regular behavior, I think testing non-typical cases like
- Basic proxy authentication support
- Server requesting login
There's also the above including various proxy configurations.
> 2) Implementing that 'misbehavior' with this codebase...probably by
necessity prior to IP approval
- This is has already been approved as part of the review of
http://dev.eclipse.org/ipzilla/show_bug.cgi?id=1765 The archive that
got submitted for review contained the necessary code so we can start
using it. We should just have to open a piggyback CQ.
RE: CQ, OK, if you say so :). We've already got piggyback approval for
use of httpclient 3.0.1:
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1096, so I suppose that
if you are right about the above including the test server code then we
can begin using it. The server code does *not* seem to be in the
httpclient Orbit bundle currently.
It's becoming quite clear that I am personally not going to have the
resources to take this on myself, so someone else is going to have to be
identified to initiate this work (i.e. setting up httpserver on test
machines, mods to httpserver to support above tests, setting up running
automated tests).
> 3) Having some public server resources to test with (as I don't
believe localhost testing is going to be sufficient)
>
> We (ECF team) have access to two servers at OSUOSL that can probably be
> used for some of 3 (since some of the 'misbehavior' cases probably
> should/would involve proxies, etc., then these servers cannot be used
> for such tests).
I agree that this would be good, however this does not seem to be a
must have to start with. Do you suggest that we would run the same
misbehaving servers locally and remotely?
Yes. The reason I think this is important because problems of server
misbehavior are frequently (almost typically) timing related, and it's
quite likely, I think, that running localhost tests may not show such
any such problems.
Scott