[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TSA messages for http ?
> >
> > > another TSA (what is actually quite possible), I would have
> > > to deal with all the socket-based things like polling, negative
> > > reply, etc.
> > >
> > > At the moment, in such cases, I return an error, but well,
> > > it is not very correct, from my point of view...
> > IMHO the polling feature in the socket transport protocol is
> > not a feature of the TSP protocol, if there is a transport
> > mapper between HTTP and the socket protocol, then the
> > http server would just waitabit and loop if there are responses
> > for polling.
> >
>
> Yes, I agree, but this means that a HTTP solution could be
> quite different from a socket-based solution.
Not really. In an HTTP transport protocol the client must
be prepared to handle http error events, location etc. This
is probably more work that an reaction to a poll request.
> On the other hand, to wait "a little" is no solution.
> You know exactly that the pollRep and the partialMsgRep include
> a so-called time to check back. So, at least theoretically,
> I should wait the specified time (10-20-60 seconds, why not?)
> and then try again.
> This doesn't sound like a good solution...
Aren't you describing a garbage in/garbage out situation?
Why don't You want to wait 10-60 seconds? because there
may actually be a MIM attack? Or, if your HTTP front ends
policy requires to reply within 10 seconds, then you may
want to create an error message saying that the time source is
not available.
Anyway, if Your TSA that uses the socket protocol has a strange
behaviour, there is no need to correct this in a HTTP frontend.