723906 - 301 on PUT only partially honored

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[firefox]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

When creating a new event on a CalDAV server, Lightning sends a PUT request with an "If-None-Match: *" header. The CalDAV RFC does not specify how the client and server should interact in case the server denies PUTting to the specified resource, so I follow the underlying HTTP RFC (http://tools.ietf.org/html/rfc2616#section-9.6): "If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.".

Lightning honors the 301 it gets, and retries the PUT to the URI specified in the Location header of the 301 response. However, the REPORT request Lighting issues afterwards, is issued containing the URI with the GUID that Lightning came up with, not the new URI from the Location header.


Actual results:

Request 1:

	PUT <host>/calendars/Test/2fb559b2-b7ad-402f-b022-dd962d1a7d83.ics HTTP/1.1
	User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 Lightning/1.2.1
	If-None-Match: *
	[...]

	BEGIN:VCALENDAR
	[...]
	END:VCALENDAR

Response 1:

	HTTP/1.1 301 Moved Permanently
	Location: <host>/calendars/Test/790.ics
	[...]
	
	<host>/calendars/Test/790.ics

Request 2:

	PUT <host>/calendars/Test/790.ics HTTP/1.1
	[...]

	BEGIN:VCALENDAR
	[...]
	END:VCALENDAR

Response 2:

	HTTP/1.1 201 Created
	[...]

Request 3 (erroneous):

	REPORT <host>/calendars/Test/ HTTP/1.1
	[...]

	<?xml version="1.0" encoding="UTF-8"?>
	<calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
	  <D:prop>
		<D:getetag/>
		<calendar-data/>
	  </D:prop>
	  <D:href>/calendars/Test/2fb559b2-b7ad-402f-b022-dd962d1a7d83.ics</D:href>
	</calendar-multiget>
	



Expected results:

I expect request 3 to contain:

	REPORT <host>/calendars/Test/ HTTP/1.1
	[...]

	<?xml version="1.0" encoding="UTF-8"?>
	<calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
	  <D:prop>
		<D:getetag/>
		<calendar-data/>
	  </D:prop>
	  <D:href>/calendars/Test/790.ics</D:href>
	</calendar-multiget>

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Sounds reasonable, we should change that some time. It shouldn't be too hard to solve!

Comment 2

[saran]

Hi I am new here and would like to help out.. Could you guide me how to proceed ? Thanks.

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Hi saran! Glad to hear you would like to help out! You are coming just at the right moment, I have just found another bug related to this :-) 

First of all you should get Lightning built: https://developer.mozilla.org/En/Simple_Thunderbird_build


Also, are you from NUS? If so, there are some colleagues of yours that have already got Lightning running and all the aliases that make it easier to work with set up, you might want to talk to them.

Afterwards, let me know via email then I will give you further steps. If you have any build errors you can't fix on your own, also email me.

Comment 4

[saran]

@philipp: I have built Lightning. Could you let me know how to proceed from here ?

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

From memory, there is the mItemInfoCache in calDavCalendar.js and calDavRequestHandlers.js. You will need to make sure the redirected URI is saved, instead of the original path. Check out the addTargetCalendarItem method, this seems to be one of the locations where the locationPath is saved.

Comment 6

[saran]

When i checked calDavCalendar.js , in the addTargetCalendarItem() accepts path and aURI.
If I am right , it should be locationPath= aURI ; ?

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The best way to solve this would be for Lightning to implement rfc 5995. I'm mutating this bug to do so. If thats not supported by the server it probably wouldn't hurt to check the final uri in the response though.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Actually, thats probably a bit too much at once. I'll file a new bug for it.

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v1

Comment 10

[Matthew Mecca [:mmecca]]

Comment on attachment 8497596 [details] [diff] [review]
Fix - v1

Review of attachment 8497596 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. r=mmecca

Comment 11

[Patrick Cloke [:clokep]]

https://hg.mozilla.org/comm-central/rev/045500468222