[TIMOB-2580] 1.5.0: HTTP 302 response headers missing

GitHub Issue	n/a
Type	Bug
Priority	Low
Status	Closed
Resolution	Duplicate
Resolution Date	2011-04-15T03:23:24.000+0000
Affected Version/s	n/a
Fix Version/s	Release 1.6.0 M05
Components	iOS
Labels	1.5.0, httpclient, ios, release-1.6.0, response, xhr
Reporter	tom quas
Assignee	Reggie Seagraves
Created	2011-04-15T03:23:23.000+0000
Updated	2017-03-03T05:45:41.000+0000

Description

My app talks to a backend service to upload images. After successful upload, the service responds with a 302, setting the Location: header to the URL of the image.

The app works with Ti 1.4.2. With 1.5.0, the Location: header is missing from the response.

Client code:
xhr.open('POST', url, false);
xhr.onload = function() {
location = xhr.getResponseHeader('Location');
after_upload_callback(location);
};

xhr.setRequestHeader('Content-Type', 'form-data');
xhr.setRequestHeader("Cache-Control", "no-cache");
xhr.send({ file:media });

Comments

tom quas 2011-04-15

After further investigation, I figured that the server returns a 200 response. The image upload works. Still, any response headers are missing with 1.5.0. FWIW, I attached the server code snippet.

class UploadHandler(blobstore_handlers.BlobstoreUploadHandler):

   def get(self):
       pass
   
   def post(self):
       """ Stores a BLOB and returns its key."""
       blob_info = self.get_uploads()[0]
       asset_info = AssetInfo(blob=blob_info.key())
       asset_info.put()
       self.redirect('/serve/%s' % asset_info.key().id())   # invokes ServeHandler

class ServeHandler(webapp.RequestHandler):

   def post(self, asset_id):
       self.response.headers['Pragma'] = 'no-cache'
       self.response.headers['Cache-Control'] = 'no-cache, no-store, must-revalidate, pre-check=0, post-check=0'
       url = "%s/asset/%s" % (self.request.host_url, asset_id)
       self.response.headers['Location'] = url

tom quas 2011-04-15

fixed w/ 1.5.1. thx.
Stephen Tramer 2011-04-15

Duplicate of other 1.5.x response header bugs.
tom quas 2011-04-15

duplicate of... which ticket? I still need to follow progress on this issue.

thx, stephen
Stephen Tramer 2011-04-15

You yourself said that the issue was fixed in 1.5.1. This was part of the HTTPResponse refactor to allow access to underlying properties of the client. I'm unable to get a bug number because lighthouse sucks.
tom quas 2011-04-15

Ah, I misinterpreted this. Duplicate == closed. Thx
Lee Morris 2017-03-03

Closing issue due to time passed and irrelevance of the ticket.

JSON Source