Bug 106734 - server caps exchange seems broken
Summary: server caps exchange seems broken
Alias: None
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Backend   
(Show other bugs)
Version: rhn290
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Fanny Augustin
Depends On:
Blocks: 106631
TreeView+ depends on / blocked
Reported: 2003-10-10 00:23 UTC by Adrian Likins
Modified: 2007-04-18 16:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-15 00:18:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Adrian Likins 2003-10-10 00:23:00 UTC
Description of problem:

        here is what I think
is happening.
if (call == queue.get or call == up2date.login):
        if call.has_caps:
        if call.has_caps:
                # 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
the caps.
It also seem like, if I make any call,
and dont include caps, it nullifies
the caps.
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.

Comment 1 Mihai Ibanescu 2003-10-10 22:47:44 UTC
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...

Comment 2 Adrian Likins 2003-10-13 17:47:56 UTC
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 
seems wrong.

Comment 3 Adrian Likins 2003-10-14 23:36:25 UTC
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. 

Note You need to log in before you can comment on or make changes to this bug.