I'm trying to create an uploading control in MVC3.
At first i've tried with javascript and HTML5 to create upload control, but that doesn't work with any of the IE versions. So,i've move to this flash version of uploadify.
I'm getting HTTP Error: 405 when uploading
Here is my code in javascript for uploadify
$(function () {
$('#file_upload').uploadify({
debug:true,
'swf': '/Content/uploadify/uploadify.swf',
'uploader': '/Content/uploadify/uploadify.php',
'cancelImg': '/Images/uploadify-cancel.png',
'script': '/Home/Uploadify',
'folder': '/Content/uploads',
auto: true
});
});
I've even tried with debug: true to see what was gone wrong, but i couldn't get what is wrong.
Here is my output with debug:
---SWFUpload Instance Info---
Version: 2.2.0 2009-03-25
Movie Name: SWFUpload_0
Settings:
upload_url: /Content/uploadify/uploadify.php
flash_url: /Content/uploadify/uploadify.swf?preventswfcaching=1355289873808
use_query_string: false
requeue_on_error: false
http_success:
assume_success_timeout: 30
file_post_name: Filedata
post_params: [object Object]
file_types: *.*
file_types_description: All Files
file_size_limit: 0
file_upload_limit: 0
file_queue_limit: 999
debug: true
prevent_swf_caching: true
button_placeholder_id: file_upload
button_placeholder: Not Set
button_image_url: /
button_width: 120
button_height: 30
button_text:
button_text_style: color: #000000; font-size: 16pt;
button_text_top_padding: 0
button_text_left_padding: 0
button_action: -110
button_disabled: false
custom_settings: [object Object]
Event Handlers:
swfupload_loaded_handler assigned: false
file_dialog_start_handler assigned: true
file_queued_handler assigned: true
file_queue_error_handler assigned: true
upload_start_handler assigned: true
upload_progress_handler assigned: true
upload_error_handler assigned: true
upload_success_handler assigned: true
upload_complete_handler assigned: true
debug_handler assigned: true
SWF DEBUG: SWFUpload Init Complete
SWF DEBUG:
SWF DEBUG: ----- SWF DEBUG OUTPUT ----
SWF DEBUG: Build Number: SWFUPLOAD 2.2.0
SWF DEBUG: movieName: SWFUpload_0
SWF DEBUG: Upload URL: /Content/uploadify/uploadify.php
SWF DEBUG: File Types String: *.*
SWF DEBUG: Parsed File Types:
SWF DEBUG: HTTP Success: 0
SWF DEBUG: File Types Description: All Files (*.*)
SWF DEBUG: File Size Limit: 0 bytes
SWF DEBUG: File Upload Limit: 0
SWF DEBUG: File Queue Limit: 999
SWF DEBUG: Post Params:
SWF DEBUG: ----- END SWF DEBUG OUTPUT ----
SWF DEBUG:
SWF DEBUG: Event: fileDialogStart : Browsing files. Multi Select. Allowed file types: *.*
SWF DEBUG: Select Handler: Received the files selected from the dialog. Processing the file list...
SWF DEBUG: Event: fileQueued : File ID: SWFUpload_0_0
SWF DEBUG: Event: fileDialogComplete : Finished processing selected files. Files selected: 1. Files Queued: 1
SWF DEBUG: StartUpload: First file in queue
SWF DEBUG: Event: uploadStart : File ID: SWFUpload_0_0
SWF DEBUG: ReturnUploadStart(): File accepted by startUpload event and readied for upload. Starting upload to /Content/uploadify/uploadify.php for File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress (OPEN): File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress: File ID: SWFUpload_0_0. Bytes: 846359. Total: 846359
SWF DEBUG: Event: uploadError: HTTP ERROR : File ID: SWFUpload_0_0. HTTP Status: 405.
SWF DEBUG: Event: uploadComplete : Upload cycle complete.
Can anyone tell me, where am i wrong ?
EDIT:
This is the request responce tracked from Fiddler:
POST /Content/uploadify/uploadify.php HTTP/1.1
Host: localhost:6930
Connection: keep-alive
Content-Length: 561702
Origin: http://localhost:6930
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
Content-Type: multipart/form-data; boundary=----------Ef1Ij5Ef1cH2GI3GI3ei4Ij5ae0gL6
Accept: */*
Referer: http://localhost:6930/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP/1.1 405 Method Not Allowed
Cache-Control: private
Allow: GET, HEAD, OPTIONS, TRACE
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.0
X-SourceFiles: =?UTF-8?B?YzpcdXNlcnNcYWRtaW5pc3RyYXRvclxkb2N1bWVudHNcdmlzdWFsIHN0dWRpbyAyMDEyXFByb2plY3RzXERhdGVBbmRUaW1lQ29udHJvbFxEYXRlQW5kVGltZUNvbnRyb2xcQ29udGVudFx1cGxvYWRpZnlcdXBsb2FkaWZ5LnBocA==?=
X-Powered-By: ASP.NET
Date: Wed, 12 Dec 2012 10:03:44 GMT
Content-Length: 5506
I've solve my problem finally. Its the uploader that troubled me.
the uploader should be the action of the controller in mvc.
Here is the solution:
$(function () {
$('#file_upload').uploadify({
debug:true,
'swf': '/Content/uploadify/uploadify.swf',
'uploader': '/Home/Uploadify',
auto: true
});
});
Related
why URI module ignores body. I need to send body to get the response what I need. Python request module works fine.
---
- name: Get info
hosts: local_host
gather_facts: no
vars:
auth_key: 'xxxxxx'
tasks:
- name: Fetch all entries matching
uri:
url: "https://get_changes.com?"
method: GET
headers:
Content-Type: "application/json"
Accept: "application/json"
Authorization: 'Basic {{auth_key}}'
Timeout: '30'
body_format: json
body:
sysparm_fields: "number, state"
sysparm_query:"cur_state=10^number=abcdef^u_ci_infra_type=network^name=Network"
return_content: yes
status_code: 200
register: crb_output
Ah I see. That's true. Args should be in URL itself for GET. forgot about that. Thanks.
I trying to use taurus and test my restapi.
My restapi using JSON body in POST requests.
So i can't find anywhere how to put json into my POST request.
I tryed like this, but this not work.
execution:
- concurrency: 25
throughput: 25
ramp-up: 1m
hold-for: 5m
steps: 3
scenario: blazemeter-recording
scenarios:
blazemeter-recording:
timeout: 5s
retrieve-resources: false
store-cache: true
store-cookie: false
default-address: https://someurl
headers:
User-Agent: 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36'
Accept-Language: 'ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4'
Accept-Encoding: 'gzip, deflate, sdch'
Accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp'
requests:
- url: '/api/v8/url/url/url'
method: POST
label: '/api/v8/url/url/url'
headers:
Content-Type: application/json
body:
"{\"applicationId\":1,\"objectId\":196,\"tags\":[{\"tag\":\"#ObjectsFilter:filter:Data#\",\"objectId\":196,\"pagination\":{\"pageSize\":100}}]}"
I found solution, i can use "body-file"
- url: 'url'
method: POST
label: 'data label'
headers:
Content-Type: application/json
body-file: /var/tests/json_event_filter.json
Your configuration is just fine, looking into Taurus JMeter Executor HTTP Requests documentation
body: 'request-body-string' # if present, will be used as body
You can double check it by running Taurus in GUI mode like:
bzt your-test.yaml -gui
or
bzt -o modules.jmeter.gui=true your-test.yaml
You should see that HTTP request sampler has your JSON payload in the "Body Data" tab:
More information: Navigating your First Steps Using Taurus
when i am trying to upload the image in the web application using POST method of HTTP using Jmeter ,Its throwing error as below
Sampler Request:
Size in bytes: 436
Headers size in bytes: 335
Body size in bytes: 101
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 405
Response message: Method Not Allowed
Response headers:
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS, TRACE
Content-Length: 101
Content-Type: text/html
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=a1634f39ccba9517317254d32be7078bb62c2877a947d85cab990f2708382045;Path=/;Domain=revflexsit.azurewebsites.net
Date: Tue, 28 Jun 2016 10:04:41 GMT
HTTPSampleResult fields:
ContentType: text/html
DataEncoding: null
Request:
POST http://revflexsit.azurewebsites.net/#//testerprofile
POST data:
--8WPDqrXY5glD81_9CcLHn-xfOTrWvH4Dh4srjx
Content-Disposition: form-data; name="profileUploadPhoto"; filename="Tulips.jpg"
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
<actual file content, not shown here>
--8WPDqrXY5glD81_9CcLHn-xfOTrWvH4Dh4srjx--
[no cookies]
Request Headers:
Connection: keep-alive
Content-Length: 621121
Content-Type: multipart/form-data; boundary=8WPDqrXY5glD81_9CcLHn-xfOTrWvH4Dh4srjx; charset=US-ASCII
Host: revflexsit.azurewebsites.net
User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_40)
Response Data:
The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.
The server response is pretty much self-explanatory, you're not allowed to make POST requests to that URL, only GET, HEAD, OPTION and TRACE ones.
Why just not to record your test scenario using HTTP(S) Test Script Recorder and modify the resulting test "skeleton" as required?
If you are still eager to build your scenario manually,looking into the http://revflexsit.azurewebsites.net/ site, it seems correct request will look something like:
Path: /api/TesterProfile/UploadTesterProfile?Id=${YOUR_ID_HERE}&UpdateAdminId=0&dimensions=x,y,x,y
Files Upload:
File Path: full path to image, you're trying to upload
Parameter Name: profileUploadPhoto
MIME Type: relevant photo MIME Type
Don't forget to tick "Use multipart/form-data for POST" box.
See How to Test Image Upload Functionality With JMeter for more detailed explanation.
In Opera only I receive "JSON.parse: Unterminated string" when going to http://www.underfashion.nl/babys
The string is indeed unterminated, does not end with "]}.
In the other browsers (IE, FF, Chrome) it works fine and receives the entire string.
The string is very long: 217529 chars. Is that possibly the problem? The other browsers receive 220374 chars ending with "]}
I have tried 3 AJAXways to get the data, all with the same strings as result:
The first:
var value = (function () {
var val = null;
$.ajax({'async': false, 'global': false, 'url': uf_urlsearch,
'success': function (data) { val = data;
alert("Data Loaded: " + data.slice(-100) + "<br/>Numofchars: " + data.length);
}
});
return val;
})();
The second:
$.get(uf_urlsearch, function(data){
alert("Data Loaded: " + data.slice(-100));
});
The third:
uf_XMLHttpProductlist.onreadystatechange=function(){
if (uf_XMLHttpProductlist.readyState==4 && uf_XMLHttpProductlist.status==200){
//Get the returned menu-items in Responsetext, expected to look like this:
...
};//if (uf_XMLHttp.readyState==4 && uf_XMLHttp.status==200){
};//uf_XMLHttp.onreadystatechange=function()
uf_urlsearch = "http://www.underfashion.nl/php/get_productlist.php?"+uf_PHPsearchstring;
uf_XMLHttpProductlist.open("GET",uf_urlsearch,true);
uf_XMLHttpProductlist.send();
};
Anyone see any solution?
Best regards,
To inspect the network activity, Go to Opera Menu -> Tools -> Advanced -> Opera Dragonfly. Then enter the URL in your addressbar.
In the Network Tab you can see the list of resources. Select the XHR button, and you will see the get_productlist.php resource. For what is worth, I didn't have any issue with your Web site. The HTTP Request was:
GET /php/get_productlist.php?afdeling=babys HTTP/1.1
User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.4; U; fr) Presto/2.10.289 Version/12.00
Host: www.underfashion.nl
Accept-Language: fr,en;q=0.9,en-US;q=0.8,ja;q=0.7,pt;q=0.6,de;q=0.5,zh-CN;q=0.4,es;q=0.3,it;q=0.2,nl;q=0.1,sv;q=0.1,nb;q=0.1,da;q=0.1,fi;q=0.1,zh-TW;q=0.1,ko;q=0.1,pl;q=0.1,pt-PT;q=0.1,ru;q=0.1,ar;q=0.1,cs;q=0.1,hu;q=0.1,tr;q=0.1,ca;q=0.1,el;q=0.1,he;q=0.1,hr;q=0.1,ro;q=0.1,sk;q=0.1,th;q=0.1,uk;q=0.1
Accept-Encoding: gzip, deflate
Referer: http://www.underfashion.nl/babys
Cookie: JSESSIONID=9ABC3B0357487E01298EBC7A02B5FDCD; __atuvc=1%7C25; __utma=137714676.906129982.1340200451.1340200451.1340200451.1; __utmb=137714676.1.10.1340200451; __utmc=137714676; __utmz=137714676.1340200451.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmv=
Connection: Keep-Alive
X-Requested-With: XMLHttpRequest
Accept: */*
Now the HTTP Response is interesting:
HTTP/1.1 200 OK
Date: Wed, 20 Jun 2012 13:54:11 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.15
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 11469
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Then the json content. Do you see what is wrong in the HTTP response above? YUP.
Content-Type: text/html
The mime type for JSON is defined in RFC 4627. Please send with JSON content the following mime type.
Content-Type: application/json
That said You are saying that you still have the issue (I don't) on some specific URIs. Could you share which one?
I have a web page containing a filtering text box and a list box. Modifications to the text box trigger an AJAX request, which returns an array of values with which to populate the list box.
I had problems with these calls failing sometimes, dependent on the size of the data returned. Small-sized returned data would result in an error, large-size data was returned and processed succesfully.
This problem only happens when I use a jQuery version greater than 4.2. If I use jQuery version 4.2, I don't have the problem.
Here is the code of the call:
jQuery.ajax(
{
cache: false,
url: "../Services/CmsWebService.svc/GetAvailableVideosForCompany",
type: "GET",
complete: function (jqXHR, textStatus) {
var responseText = jqXHR.responseText;
jQuery('#debugConsole').text(responseText);
availableVideosPopulationState.isRunning = false;
setTimeout(populateAvailableVideosListBox, 100);
},
data: { "companyIdString": queryParameters.companyIdField,
"textFilter": queryParameters.filterText
},
dataType: 'json',
error: function (jqXHR, textStatus, errorThrown) {
var errorString = 'Error thrown from ajax call: ' + textStatus + 'Error: ' + errorThrown;
alert(errorString);
},
success: function (data, textStatus, jqXHR) {
populateVideoListFromAjaxResults(data);
}
}
);
Here is the contents of the debug console if two elements are returned:
{"d":[{"__type":"ListEntry:#WebsitePresentationLayer","Text":"SOJACKACT0310DSN1.mpg - [SOJACKACT0310DSN1]","Value":"5565_5565"},{"__type":"ListEntry:#WebsitePresentationLayer","Text":"SOJACKACT0310DSN1Q.mpg - [SOJACKACT0310DSN1Q]","Value":"5566_5566"}]}
But if one element is returned:
{"d":[{"__type":"
So, of course, we get an "Unterminated String Constant" error.
I have done some investigation using fiddler.
On all responses (even the succesful ones), fiddler displayed an error:
Fiddler has detected a protocol violation in session #n1.
Content-Length mismatch: Response Header indicated n2 bytes, but
server sent n3 bytes.
If the response header indicates a size greater than than actual size, then the results could still be interpreted by the browser.
If the response header indicates a size less than the actual size, then the browser could not interpret the results.
The obvious assumption to make there is that the response handling code reads the Content-Length header and doesn't read any more data than that stipulated in the length.
The next step in my investigation is to compare the request/response headers for jQuery version 1.6.1 (which breaks) and version 1.4.2 (which does not break).
jQuery 1.6.1 request header:
GET /Web/Services/CmsWebService.svc/GetAvailableVideosForCompany?companyIdString=2&textFilter=3DSBDL2&_=1315869366142 HTTP/1.1
X-Requested-With: XMLHttpRequest
Accept: application/json, text/javascript, */*; q=0.01
Referer: http://localhost:52200/Web/Admin/PlayerGroupEditor.aspx?groupid=76
Accept-Language: en-au
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Host: localhost:52200
Connection: Keep-Alive
Cookie: .ASPXAUTH=CE853BBD860F40F0026400610074006D006500640069006100310000002B5387799D71CC01002B5B5D62C771CC0100002F0000006B119589A7305098A560E57515498C56ECB332035F300427CDA2B28205D5E6B6
jQuery 1.6.1 response headers
HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Mon, 12 Sep 2011 23:02:36 GMT
X-AspNet-Version: 4.0.30319
Content-Encoding: gzip
Content-Length: 140
Cache-Control: private
Content-Type: application/json; charset=utf-8
Connection: Close
And here is the request header when I use jQuery 1.4.1. Notice that the Accept header is different from the jQuery 1.6.1 value.
GET /Web/Services/CmsWebService.svc/GetAvailableVideosForCompany?_=1315870305531&companyIdString=2&textFilter=3DSBDL2 HTTP/1.1
Referer: http://localhost:52200/Web/Admin/PlayerGroupEditor.aspx?groupid=76
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Accept: application/json, text/javascript, */*
Accept-Language: en-au
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Host: localhost:52200
Connection: Keep-Alive
Cookie: .ASPXAUTH=CE853BBD860F40F0026400610074006D006500640069006100310000002B5387799D71CC01002B5B5D62C771CC0100002F0000006B119589A7305098A560E57515498C56ECB332035F300427CDA2B28205D5E6B6
And the response back to jQuery 4.1.1:
HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Mon, 12 Sep 2011 23:31:46 GMT
X-AspNet-Version: 4.0.30319
Content-Length: 131
Cache-Control: private
Content-Type: application/json; charset=utf-8
Connection: Close
So the obvious difference is that when the call is made via jQuery 1.6.1 the response is compressed using gzip, and when the call is made via jQuery 1.4.2 the response is not compressed.
So now I can do a work around solution, which is to override the default Accept header to ensure it does not contain the "q=0.01" string. (The best explanation I can find for "q=0.01" is here, but I fail to see why my service implementation is interpreting this as a request to zip up the response badly.)
// Make the AJAX call, passing in the company id and the filter string
jQuery.ajax(
{
accepts: 'application/json, text/javascript, */*',
cache: false,
url: "../Services/CmsWebService.svc/GetAvailableVideosForCompany",
type: "GET",
complete: function (jqXHR, textStatus) {
var responseText = jqXHR.responseText;
jQuery('#debugConsole').text(responseText);
availableVideosPopulationState.isRunning = false;
setTimeout(populateAvailableVideosListBox, 100);
},
data: { "companyIdString": queryParameters.companyIdField,
"textFilter": queryParameters.filterText
},
dataType: 'json',
error: function (jqXHR, textStatus, errorThrown) {
var errorString = 'Error thrown from ajax call: ' + textStatus + 'Error: ' + errorThrown;
alert(errorString);
},
success: function (data, textStatus, jqXHR) {
populateVideoListFromAjaxResults(data);
}
}
);
So after all this investigation, the remaining question is why is there a disparity between the content length header and the actual content length when the response is GZIP compressed?
I'm using a WCF service with webHttpBinding.
First of all-Very good question. This question provided me with enough information to reach a solution for my problem.
I had a similar issue, and posting the fix here- so that it might help someone.
Ajax get & post requests were returning null in IE
Was working fine in rest of the browsers, but saw the 'Response Header indicated n bytes, but server sent nn bytes' message in fiddler for the request.
The obvious assumption to make there is that the response handling
code reads the Content-Length header and doesn't read any more data
I think so too!
In this case, I was clear with one thing. Something was tampering the request/response.
I tried switching back to older version of jQuery (as mentioned in your question), but that didn't help.
Fix-
I opened up the web config of my application, and read through it.
There was a 'RadCompression Module' from telerik included in modules, and on removal of it everything started working fine.
RadCompression module is known to be buggy and cause multiple issues by compressing the Response.
If you are having similar issues, try checking what might be intercepting your request/response.
Response Header indicated 140 bytes, but server sent 254 bytes says much. Does the same happen independently of the browser you use? If so, we may say that IE or jQuery 1.4.3 and further in IE does not read bytes after reading as many bytes as specified in Response Header, while other browsers read all the content anyway.
It is also possible (yet I hardly believe this) that response header is wrongly formed only for IE requests. Then you must look at the differences between IE and other browser requests and your service code. Maybe your services handles IE requests specifically?
It would be interesting to calculate how much bytes there is after the last captured quotation mark (") in your JSON string. 114 maybe?