[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