404 error when uploading file to GCS with query string on Production

I am using flash to upload a file to GCS.

I create a upload url using the following successUrl

"/cms/requestManager?ps={"1":{"action":"Upload Audio Recording","sendId":1,"data":{"fileName":"testQuestionAudioRecording","category":"testQuestionRecording"}},"jsInstanceID":"ahdzfmRldi1keW5hY3RpdmVzb2Z0d2FyZXITCxIKSlNJbnN0YW5jZRjKm-kBDKIBBmRzLmNtcw","userActive":true}"

When I send the file upload it comes back with a 404 error.

I check in the appengine instance logs for 404 errors and there are none.

The file I tried to upload does show up in the GCS bucket.

In the documentation for blobstoreService.createUploadUrl() it does not mention that query strings are not allowed. I would also expect that if there were something wrong with the successUrl that an IllegalArgumentException would be thrown.

If I go directly to the successUrl it will respond correctly with JSON data.

This is the link if you want to test

On my local test server it works fine. So I am seeing this issue only on production.

If I take out the query string, it will work. If I add a simpler query string like /cms/requestManager?blah=blah it will not work.

Does anyone have any ideas what is going on?

Is there a way to see what is happening on at /_ah/upload?

Could it be possible that it is 404ing on my end but not logging it? If so, what can I do find that out?

Here is the post and response headers and content.

Response Header:

HTTP/1.1 404 Not Found

Content-Length: 0

Date: Fri, 06 Mar 2015 00:25:25 GMT

Server: UploadServer ("Built on Feb 18 2015 18:10:26 (1424311826)")

Content-Type: text/html; charset=UTF-8

Alternate-Protocol: 80:quic,p=0.08

Request Headers:

POST /_ah/upload/AMmfu6a-yuYk7Gm1YMtqLt-GgyizWYLXRStoAZ49FCNNRHIVXMFrRh0Jo1aCSXf4c8uXrjJnCQwvSq7cFdVeI1v5J59jQeVfwvR6STMbs0hBw-GncTI1JHgE4NItQd2JQGgyHIqTasjR4lK_5g8-M0Nf1YdWr29by5Mskk07tpSLNUE0mEW2IOjlWP_Usa7ObJMFdElVqIsgd5a_Bq198AB9oprS6DMHkiYKsdJGCTmHe93w_PEoi-XiROlHSpEsi8TLwQUPPC86iqQsn6th4OGoRudOcdAVhFxCq1VJjXx2frv_Lm0khSxpmOU2nQu8gsbP-IaAgVWMe-0UUgsLYdODjqJhgkr-IB1h05F50pAXTgzImQHyv7ygvOhHO0zGUBAiH1a072LJa7EiN1TXcBYcDfbbMikR5lBdaqfqHccx23RZrDiyGfR3kwMiXmgqFy5BJY5Ht9ZoYlfST76laeM5v2PSheMqweHIZQATBZ0Zxojzv1mFr3ECasfwEY98ambjjrbgqysPwg56B-EYDCwUBAV5FvzY6hIGKnhjun9-rorrx0CuKww/ALBNUaYAAAAAVPj2QZXMlxhUs1-Au6wnswd3PTvLwL_G/ HTTP/1.1

Host: dev-dynactivesoftware.appspot.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:36.0) Gecko/20100101 Firefox/36.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.7,es;q=0.3

Accept-Encoding: gzip, deflate

Cookie: ahdzfmRldi1keW5hY3RpdmVzb2Z0d2FyZXITCxIKSlNJbnN0YW5jZRjKm-kBDKIBBmRzLmNtcw=1425601513386

Connection: keep-alive

appid = dev-dynactivesoftware

successUrl length = 256

Link to blobstoreService.createUploadUrl documentation

UPDATE:

I wrote some stuff into our system that allowed for data that was in the query string to be put into the url. So instead of /requestManager?ps={} it would be

/requestManager/My Action/lsdkjfalsdkfjaldkfjaldkjf

It also 404d so I changed it to have no spaces in the url.

/requestManager/MyAction/lsdkjfalsdkfjaldkfjaldkjf

and it did not 404.

Could it be that the upload service is having problems using successUrls that have special characters in it, like spaces and ?.

SOLVED:

the successUrl that you send into blobstoreService.createUploadUrl() needs to be url encoded first. So I modified the code that gets the uploadUrl to be the following:

String successUrl = URLEncoder.encode("/requestManager/My Action/askldjfkajsdflkasdkjh", "UTF8");
String uploadUrl = blobstoreService.createUploadUrl(successUrl);

I also had to decode the url later so that it was usable.

It seems to me that if the successUrl has characters that need to be encoded (because the service will return a 404 if it doesn't) then it should throw "java.lang.IllegalArgumentException - If successPath was not valid."

It would also be nice if the uploadServer would return something with the 404 message to indicate that successUrl 404d and this is the url we tried. At that point we would be able to see what is going on a lot faster.

I guess the even better fix would be to just put the code that the dev server runs on live because the dev environment worked perfect.