Closed
Bug 462026
Opened 16 years ago
Closed 16 years ago
301 and 302 redirects not done properly with caldav provider
Categories
(Calendar :: Provider: CalDAV, defect)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b1
People
(Reporter: nomisvai, Assigned: Fallen)
Details
Attachments
(1 file)
15.25 KB,
patch
|
dbo
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/20080917 Sunbird/0.9 If a server responds with a 301 or 302 response code, the client will do a GET http method instead of the previously redirected method. To reproduce you can try a http:// connection to our hosted server (caldav.oracle.com) it should redirect to https:// of the same url. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Assignee | ||
Comment 1•16 years ago
|
||
I believe we need to resetup the channel in case of a redirect, I think we forgot to do that when fixing the original bug. Will look into this.
Assignee: nobody → philipp
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Updated•16 years ago
|
Flags: blocking-calendar1.0+
Assignee | ||
Comment 2•16 years ago
|
||
After a lot of sweat and blood, I was finally able to find all problems regarding redirection. Since the most common use of 3xx redirects is to redirect from http -> https, we might want to actually change the internal URL in case that is the only change to reduce the number of requests done, but I'll leave this to a different bug.
Attachment #345304 -
Flags: review?(daniel.boelzle)
Comment 3•16 years ago
|
||
Comment on attachment 345304 [details] [diff] [review] Fix - v1 the patch looks good, athough I haven't tested it; r=dbo I am wondering if ics/gdata/wcap would benefit from such a fix, too?
Attachment #345304 -
Flags: review?(daniel.boelzle) → review+
Assignee | ||
Comment 4•16 years ago
|
||
GData already takes care of redirects but in a different way. Not sure if/how wcap does so. A helper in calProviderUtils.js might be a good idea, with a list of headers to copy. Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/093282385810> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Comment 5•16 years ago
|
||
Anybody knows about ics? Philipp, could you write a follow-up bug or should we use this one to complete the works w.r.t. ics/wcap?
Assignee | ||
Comment 6•16 years ago
|
||
ICS seems to work out of the box. I don't have a wcap server that redirects to test this.
Comment 7•16 years ago
|
||
What about using a proxy server? cal-emea uses https.
Assignee | ||
Comment 8•13 years ago
|
||
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•