478330 - Client-side X-WEAVE-ALERT support

Status: RESOLVED WONTFIX

(Cloud Services :: General, defect, P2)

Description

[Dan Mills [:thunder]]

The server is sending a new header, X-WEAVE-ALERT, for the server to inform the client about various error conditions (like quotas, downtime notifications, etc).

Comment 1

[Dan Mills [:thunder]]

-> 0.4

Comment 2

[Anant Narayanan [:anant]]

Attachment: Handle X-Weave-Alert header

We display a notification (or replace an existing one), everytime we receive a X-Weave-Alert header from the server. Tested with a sample message on the dev-server on sm-weave-proxy01.

Comment 3

[Dan Mills [:thunder]]

Comment on attachment 392358 [details] [diff] [review]
Handle X-Weave-Alert header

I think Resource should capture this info and pass it up somehow, instead of jamming UI code into our lowest-level js networking code.

Also, having it stored somewhere and higher up the stack would allow us to have other behaviors, e.g. displaying a warning on the quota meter in about:weave.

Comment 4

[Anant Narayanan [:anant]]

Attachment: Handle X-Weave-Alert header (v2)

Better, modular support for displaying X-Weave-Alert's to the user. Issues to be dealt with:

1. Decide on the JSON format to be sent in X-Weave-Alert
2. Decide on codes for each type of alert
3. Intepret the codes on the client and display appropriate notifications (including ones that cannot be dismissed by the user)

Comment 5

[Anant Narayanan [:anant]]

The patch also changes the semantics of Resource.get() which now returns a RequestResponse object instead of just the responseText, so that the status code and headers can be queried by the caller without using Resource.lastRequest

Comment 6

[Mike Connor [:mconnor]]

If we're doing that, which I don't object to, can we make the status property not throw if the channel is wacky?  Would let us simplify a lot of stuff I'm doing in bug 481733...

Comment 7

[Dan Mills [:thunder]]

(In reply to comment #4)
> Created an attachment (id=395220) [details]
> Handle X-Weave-Alert header (v2)
> 
> Better, modular support for displaying X-Weave-Alert's to the user. Issues to
> be dealt with:
> 
> 1. Decide on the JSON format to be sent in X-Weave-Alert
> 2. Decide on codes for each type of alert
> 3. Intepret the codes on the client and display appropriate notifications
> (including ones that cannot be dismissed by the user)

looks good, can you land this and work out 1-3 after?

Comment 8

[Anant Narayanan [:anant]]

http://hg.mozilla.org/labs/weave/rev/129ca9a54aed

Resource doesn't throw anymore if the response isn't between 200 and 300. We instead always return an object of type RequestResponse which can be queried for response data, headers and status code.

X-Weave-Alert's are, for now, a JSON array of human readable strings that are displayed as-is. We can revisit their representation at a later time.

Comment 9

[Dan Mills [:thunder]]

> X-Weave-Alert's are, for now, a JSON array of human readable strings that are
> displayed as-is. We can revisit their representation at a later time.

Please file a follow up bug for this.

Comment 10

[Ed Lee :Mardak]

The unit tests are most likely failing now -- test_resource/records_*.

Comment 11

[Ed Lee :Mardak]

Backed out changeset 129ca9a54aed due to burning
test_auth_manager: FAIL
test_resource: FAIL 

This could build on top of bug 511746. That patch exposes a .status like this patch here but it provides a .header too instead of needing to keep around the channel to call getResponseHeader.

Comment 12

[Ed Lee :Mardak]

We have various messages for backoff, and we're not doing quotas for 1.0, so sending a non-localized message to the client isn't a high priority for now.

Comment 13

[Mike Connor [:mconnor]]

We don't need this for now.  At some point, we'll have notifications if we need to do somehting like this, but probably not as a header.