Red Hat Bugzilla – Bug 106734
server caps exchange seems broken
Last modified: 2007-04-18 12:58:17 EDT
Description of problem:
here is what I think
if (call == queue.get or call == up2date.login):
# dont change the caps
aka, it looks like if I make a call thats
not queue.get or up2date.login, and I
include caps info, it ignores the caps
info I actually send, and instead nulls
It also seem like, if I make any call,
and dont include caps, it nullifies
It seems like if the last call isnt
a queue.get or up2date.login, then
the caps are always going to be
nullified. Which is kind of broken.
Checked the code, I only update the capabilities in up2date.login and queue.get.
I don't touch the client capabilities from anywhere else (do a grep on
update_client_capabilities). The capabilities are extracted from a global flag
that is set by calling set_client_capabilities. set_client_capabilities is
called from apacheHandler.py in the header parsing handler.
It is arguable if "no capabilities from the client" means the client didn't send
them (in queue.get/up2date.login) or it doesn't support capabilities anymore
(older OS, or downgrading up2date). Donno.
I can't really see how the above-mentioned scenario would work. I'll have to
test a bit...
I could be wrong, but thats the behaviour I was seeing after
a couple hours of testing.
Basically, if I send up caps info with any call other
than queue.get or login(), the caps get nullified.
no caps in queue.get or login nullifying the store
caps is fine. Even nullifying it on other calls might
be fine. But nullifying it when the caps are sent
hmm, I thought perhaps I was sending up the wrong systemid
on the login, but that does not appear to be the case.
And I still get the same behaviour.