Description of problem: Authentication errors should be evaluated prior to any other kinds of errors and the resulting behaviour WRT authentication information should not be influenced by subsequent error at all. In practice, that means that when user authenticates successfully with "prefer: persistent-auth" set, he should be given JSESSIONID cookie && header no matter how the rest of the query ends up. The desired behaviour improves UX of REST API apps (it saves roundtrips and for bad Version-Release number of selected component (if applicable): is16 / rhevm-restapi-3.3.0-0.22.master.el6ev.noarch How reproducible: always Steps to Reproduce: 1. perform a query like this with valid credentials: curl <...> -u user.org https://rhevm.example.org/api/nonsense 2. 3. Actual results: JSESSIONID cookie and headers are not sent Expected results: JSESSIONID cookie and header are sent Additional info: the example doesn't make much functional sense but it's a good reproducer. I'd expect the real use case for combination of timeout (--> need to relogin) and change of something between app refreshes
i disagree (In reply to David Jaša from comment #0) > Description of problem: > Authentication errors should be evaluated prior to any other kinds of errors > and the resulting behaviour WRT authentication information should not be > influenced by subsequent error at all. In practice, that means that when > user authenticates successfully with "prefer: persistent-auth" set, he > should be given JSESSIONID cookie && header no matter how the rest of the > query ends up. this is not correct, since our api uses ROA architecture, every resource is considered a entry point to api (unlike in SOA where you have single entry point where authenticate takes place), so you should see this as accessing incorrect address (url) in the NET.