Forum Discussion
Willy_82807
Nimbostratus
NimbostratusFileupload problem
I am new to BigIP. I am load balancing two servers both running java servlet / jsp applications. Some of the 3rd party modules are hosted in iframes and to get the content it uses a non relative url. The application as a whole needs to use https. So I created this irule.
when HTTP_REQUEST {
HTTP::redirect https://[HTTP::host][HTTP::uri]
}
But now I am getting the unintended consequence that fileuploads are working sometimes and not other times. It is not a file size issue. It happens in Firefox and IE8. This is the error message I am getting.HTTP Status 501 - Method 240776-- GET is not defined in RFC 2068 and is not supported by the Servlet API
type Status report
messageMethod 240776-- GET is not defined in RFC 2068 and is not supported by the Servlet API
descriptionThe server does not support the functionality needed to fulfill this request (Method 240776-- GET is not defined in RFC 2068 and is not supported by the Servlet API ).
Apache Tomcat/5.5.29
When I go directly to the Tomcat server (skip the load balancer) and upload the same file I do not get an error and it uploads quickly. This does not happen for every file. But I have not yet noticed the common denominator in the files that is causing the issue. Most files upload fine. I do have one that consistently throws this error that is useful for debugging.
These applications ran for a while before the BigIP appliance was installed and never had this issue. So I am concerned that the problem lies with my iRule. Any suggestions on how to go about solving this issue? A better way to do the https redirect for the iframe content or a way of logging these events so I can perhaps notice a pattern in what kind of files are causing the issue or a way to redirect file uploads so they will work.
15 Replies
Ben_95489Hey Willy,
This sound like a fairly tricky issue. Your best bet is probably going to be to try to capture this behavior happening on the wire and inspect the behavior here. This may provide additional insight.
Just to take a wild swing, though, you might want to try rewriting the links in the pages with a stream profile so that the user's browser will request the items/iframes as HTTPS to begin with. The current setup means that if a link is written as HTTP, it will be sent to the browser as such. The browser will then attempt to fetch the resource via HTTP, get a redirect, and try again as HTTPS. This could lead to some timing conditions that cause this sporadic behavior. It may not be the case, but it would probably still be best to try re-writing the content on its way to the client anyway. A stream profile is probably best for this - this thread covers how to do this in fairly good detail: http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/aff/5/aft/62191/afv/topic/Default.aspx
I'm not sure if this will correct the file upload issue, but it would certainly rule out one of the possible causes.
Cheers!
// Ben
L4L7_53191Can you take an HTTPWatch or some similar capture so we can visualize what is going on? There's a few different possibilities.
-Matt
Willy_82807Just to make it easy to spot the error. The result column = 501 in the third section of the badupload screen capture is where to error message appears.- Ben_95489Hey Willy,
Thanks for the HTTPWatch information. I'm not certain that I can discern from the logs here exactly what is taking place, but I do have a few thoughts.
First, the iRule that you originally listed - I presume this is applied to a port 80 virtual server at the same IP as the port 443 virtual server. Is that accurate?
Second, I suspect some of those 302 redirects are probably coming from the application itself during the upload process. If so, the application is probably writing its redirects as HTTP which is causing some of the doubling of effort seen in the capture. You might want to try enabling Rewrite Redirects to see if this helps: http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6912.html
It looks like something odd is certainly happening in the broken upload. If you examine the requests carefully, the second page in the failed upload looks like the actual upload attempt, at least as seen in the working upload. The error comes in the page following this, though. I don't have much to base this on, but I would look at rewrite redirects and see if that makes any difference in this behavior.
// Ben - L4L7_53191I see some mention of this error in Tomcat's bugzilla (https://issues.apache.org/bugzilla/show_bug.cgi?id=46984), but they mention it was fixed in 5.5 upward. At any rate, I'd open a support case on this - it'll go beyond just HTTPwatch I fear. One note: can you successfully upload smaller files? I see the working version is smaller than the broken one.
-Matt - Willy_82807-Matt
I am able to upload smaller files as well as larger ones. I have done 5MB files.
The Bugzilla report states at the bottomThis has been fixed in 5.5.x and will be included in 5.5.28 onwards. I am using version 5.5.29 Thank you all for so much help. 
Joel_MosesI'd be interested to see why your POSTs are getting 302 responses almost immediately.
Can you post the request and response headers for both the upload & 302, and for the 501 error? I think what's going on is that 1) your redirection is turning a POST into a GET (which the AJAX configuration doesn't recognize as valid), or 2) AJAX is not able to follow the resultant redirections properly.
When you access the site "directly" and it works, are you doing so using just HTTP? And when you do, does the server typically respond to the upload POST with a 302 or a 200?- Joel_MosesIs the last header/response pair in the screen above when the response is 501?
Yes, it's pretty interesting that some files work and some don't. Does the size of the file make any difference to the occurrance of errors?
A few more questions (bear with me):
1) How many servers are in this pool?
2) What load-balance scheme and persistence are you using, if any?
3) Any SNAT involved here?
4) Do you have an HTTP profile set, and, if so, how is it configured?
5) Are you using oneconnect? - Willy_82807Okay I have a theory. Let me know if this is totally out of left field. When the stream was rewriting. It would rewrite files that had a URL in them matching http:// this would make the files have different file sizes in transit and would cause a file size check somewhere to fail.
Now that it is switched to look for only http://learning.usuhs.mil it does not find that URL in the file and therefore does not rewrite it.
I was able to verify that it would rewrite .txt files and I think anything that was not sent as a binary stream. That's what makes me think this is possible.
Does this sound plausible or does anyone have a different theory? 
Sean_82866[quote=Willy]okay this fixed the problem. Can someone help to explain how?
I changed the profile stream it used to say http: to https:
Now it looks like this and all files are uploading correctly. I am not sure how or why this makes it work.
Because only the full URLs are being rewritten. You'll still have trouble with any files which contain links pointing towards your server being corrupted, but you'll be fine for the majority of traffic. Writing an iRule to exclude (or only include) the data types which should actually be modified is a more elegant solution.
