Develop Reference

400-Bad request- request header to long

I'm trying to generate pdf,but after like the 5th page header and footer display http error 400-bad request-request header to long. is there anyway to solve this problem? a response header can look like
this
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: // i hid the adress
Cache-Control: no-store, no-cache
Content-Disposition: attachment; filename=Utskrift.pdf
Content-Length: 162568
Content-Type: application/pdf
Date: Tue, 25 Oct 2022 08:57:16 GMT
Expires: -1
Pragma: no-cache
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET

The length you are trying to send is very large to be handled. It is like overdosing the request header. What you can do is, you can consider to break it in to chunks (smaller sizes), and send them separately until you gather all the file size on the endpoint you are sending.

How to get videoId when video is uploaded on Vimeo

How do I get the videoId after a video is uploaded on vimeo? When we call delete upload ticket, we have confirmed that the upload is successful and we are getting a response url like this url=https://api.vimeo.com/users/111243975/uploads/319650191?video_file_id=1786656414&upgrade=true&signature=4c02359068ec5a31cea3b633f6b5f9cf. Here we have video_file_id but not the actual videoId.

You're using a deprecated upload method (the "resumable" PUT method), so its documentation is no longer available on the Vimeo Developer Site. Luckily, the Internet Archive has those docs saved.
After you make the final DELETE call to that endpoint, the video uri is returned in the location header of the response.

Pow, Brow, its correct!
Location: /videos/555380765
{Connection: keep-alive
Server: nginx
Cache-Control: no-store, no-cache, private
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Location: /videos/555380765
X-RateLimit-Limit: 500
X-RateLimit-Remaining: 499
X-RateLimit-Reset: 2021-05-26T19:57:59+00:00
Request-Hash: 2461d148
X-BApp-Server: api-v10808-f5ldq
X-Vimeo-DC: ge
Accept-Ranges: bytes
Via: 1.1 varnish, 1.1 varnish
Date: Wed, 26 May 2021 19:57:00 GMT
X-Served-By: cache-bwi5155-BWI, cache-cgh11141-CGH
X-Cache: MISS, MISS
X-Cache-Hits: 0, 0
X-Timer: S1622059020.784666,VS0,VE594
Vary: Accept, Vimeo-Client-Id
Content-Length: 0
Content-Type: text/html; charset=UTF-8
}

Web API - Return JSON object along with the HTTP Status

I have this Web API function that I wish to use to return errors if any invalid data is passed in. I do this by using the Request.CreateResponse function, and passing it the error code and list of errors.
public HttpResponseMessage Post([FromBody]Lead leadToCreate)
{
// Code to validate the request, and populate errorList which is a List<Error> goes here
if (errorList.Count > 0)
{
// Return list of errors and 304 code
return Request.CreateResponse(HttpStatusCode.NotModified, errorList);
}
else
{
//Validated successfully.
return Request.CreateResponse(HttpStatusCode.Created);
}
}
The Error class is:
public class Error
{
public int number;
public string description;
public string url;
}
When I make a POST request with Fiddler on localhost, the error list is output as part of the JSON response (see the last line):
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcU291cmNlIENvZGVcV2ViXEZhc3R0cmFjayBBUElcRmFzdHRyYWNrIEFQSVxhcGlcc2FsZXNFbnF1aXJ5XDFc?=
X-Powered-By: ASP.NET
Date: Wed, 10 Feb 2016 14:49:20 GMT
[{"number":1,"description":"PrivateIndividual.Gender must be valid.","url":""}]
My problem is that after publishing to my live server, the error list isn't output despite using the same request data, although the correct response code is returned:
HTTP/1.1 304 Not Modified
Cache-Control: no-cache Pragma: no-cache Content-Type: application/json; charset=utf-8
Expires: -1 Server: Microsoft-IIS/7.0
X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Wed, 10 Feb
2016 14:52:13 GMT Connection: close X-ScanSafe-Error: F284 Via:
HTTP/1.1 proxy10012
Can anyone see why this may be working fine on localhost, but not my live server?

It looks like there is an application layer proxy having a problem with the response:
2016 14:52:13 GMT Connection: close X-ScanSafe-Error: F284 Via:
HTTP/1.1 proxy10012
And it looks like this proxy is blocking the HttpResponse from getting back to fiddler.

Twitter API, Tweets with Images, Error Code 324 "The validation of media ids failed."

I have been able to successfully post status updates with images attached. I am using C#/.NET with a REST framework called Hammock. First, I upload the images to upload.twitter.com/1.1/media/upload.json and get media_ids back. Then, I make a request to api.twitter.com/1.1/statuses/update.json with the media_ids parameter. This works fine except that occassionally, with larger images, Twitter responds to my status update request with the following JSON:
{"errors":[{"code":324,"message":"The validation of media ids failed."}]}
I have tried waiting several minutes between the time of media upload and status update with no success. I have also posted on Twitter's developer forums, but posting here as well in case anyone has experienced this and has any insight. https://twittercommunity.com/t/the-validation-of-media-ids-failed-error-code-324/29304 I don't see "324" anywhere in Twitter's API documentation, especially here: https://dev.twitter.com/overview/api/response-codes
Here are the exact (except for sensitive values being xxxx'd out) requests/responses seen in Fiddler:
Media Upload Request
POST https://upload.twitter.com/1.1/media/upload.json HTTP/1.1
Authorization: OAuth oauth_consumer_key="xxxxxxxxxxx",oauth_nonce="xxxxxxxxxxx",oauth_signature="xxxxxxxxx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1418763417",oauth_token="xxxxxxxxxx",oauth_version="1.0a"
Content-Type: multipart/form-data; boundary=5fb9e9e7-25cf-49fd-b5ef-61aefed2897e
Host: upload.twitter.com
Content-Length: 2399916
--5fb9e9e7-25cf-49fd-b5ef-61aefed2897e
Content-Disposition: form-data; name="media"; filename="d1cd395d-bebf-4733-aedc-680327ef63ec"
Content-Type: image/jpeg
Media Upload Response
HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
content-length: 140
content-type: application/json;charset=utf-8
date: Tue, 16 Dec 2014 20:56:57 UTC
expires: Tue, 31 Mar 1981 05:00:00 GMT
expires: Tue, 16 Dec 2014 21:56:57 GMT
last-modified: Tue, 16 Dec 2014 20:56:57 GMT
pragma: no-cache
server: tsa_b
set-cookie: lang=en
set-cookie: guest_id=v1%xxxxxxxx; Domain=.twitter.com; Path=/; Expires=Thu, 15-Dec-2016 20:56:57 UTC
status: 200 OK
strict-transport-security: max-age=631138519
x-access-level: read-write
x-connection-hash: xxxxxxxxxxx
x-frame-options: SAMEORIGIN
x-response-time: 344
x-transaction: xxxxxxxxx
x-xss-protection: 1; mode=block
{"media_id":544959385899122689,"media_id_string":"544959385899122689","size":4311817,"image":{"w":3000,"h":2350,"image_type":"image\/jpeg"}}
Status Update Request
POST https://api.twitter.com/1.1/statuses/update.json HTTP/1.1
Authorization: OAuth oauth_consumer_key="xxxxxxxxxx",oauth_nonce="xxxxx",oauth_signature="xxxxxxxxxxxx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1418763469",oauth_token="xxxxxxxxxxx",oauth_version="1.0a"
Content-Type: application/x-www-form-urlencoded
Host: api.twitter.com
Content-Length: 117
status=test%20test%20test&media_ids=544959385899122689%2C544959443889557504%2C544959458036957184%2C544959545941192705
Status Update Response
HTTP/1.1 400 Bad Request
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
content-length: 73
content-type: application/json;charset=utf-8
date: Tue, 16 Dec 2014 20:57:49 UTC
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Tue, 16 Dec 2014 20:57:49 GMT
pragma: no-cache
server: tsa_b
set-cookie: lang=en
set-cookie: guest_id=xxxxxx; Domain=.twitter.com; Path=/; Expires=Thu, 15-Dec-2016 20:57:49 UTC
status: 400 Bad Request
strict-transport-security: max-age=631138519
x-access-level: read-write
x-connection-hash: xxxxxxxx
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-response-time: 44
x-transaction: xxxxxxx
x-xss-protection: 1; mode=block
{"errors":[{"code":324,"message":"The validation of media ids failed."}]}

This is a result of the image being too large. I just ran in to the same issue, and resolved it by sending along a jpg version (300KB) of a largeish png (it was 1.2MB).
The stated size limit is 3MB, but they might have some kind of client-specific throttling in place.

WebAPI returning File and download is not starting

Having a very strange problem, when I'am returning a file as a "HttpResponseMessage", it works when iam returning pdf file, but when I'am returning a xls file(excel file) it does not.
Here is the response headers, I've tried changing the content type to "application/vnd.ms-excel"
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 316928
Content-Type: application/octet-stream
Content-Encoding: UTF-8
Expires: -1
Server: Microsoft-IIS/8.0
Content-Disposition: attachment; filename=f.xls
Content-Description: File transfer
Charset: UTF-8
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcZGV2XHRmc1xrYmFzcnZcZUdhaW4uV2Vic2l0ZXMuRm9yZWNhc3RpbmdcYXBpXFByaW50XENhbGxpbmdMaXN0QnlDb21wYW55T3JDdXNvdG1lcklk?=
X-Powered-By: ASP.NET
Date: Fri, 06 Dec 2013 07:49:47 GMT
the result iam getting looks like when you open the xls file in notepad.
i foudn a very strange solution that was to convert it to base64 and make a link to "data: application/octet-stream; base64, "
and that would start the download thou you dont know the name of the file so the user would not understand to save it as XLS file...
now iam back at the result that wont start the download... any suggestions?
Here comes the response Raw from fiddler2
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 316928
Content-Type: application/octet-stream
Expires: -1
Server: Microsoft-IIS/8.0
Set-Cookie:
path=/; HttpOnly
Content-Disposition: attachment; filename=f.xls
Content-Description: File transfer
Charset: UTF-8
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcZGV2XHRmc1xrYmFzcnZcZUdhaW4uV2Vic2l0ZXMuRm9yZWNhc3RpbmdcYXBpXFByaW50XENhbGxpbmdMaXN0QnlDb21wYW55T3JDdXNvdG1lcklk?=
X-Powered-By: ASP.NET
Date: Fri, 06 Dec 2013 08:40:51 GMT
��ࡱ�����������������>���� ���������������d�������������������������e��f��g��h��i������������������������������������
*** FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. ***
UPDATE
Iam calling the WEBAPI function with a post request, and i compare it with the old response result and they are almost the same.
iam posting the respnose from both requests here.
from the old method, the download starts...
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/vnd.ms-excel; charset=utf-8
Server: Microsoft-IIS/8.0
Content-Disposition: attachment; filename=CallList_2013-12-06.xls
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcZGV2XHRmc1xrYmFzcnZcZUdhaW4uV2Vic2l0ZXMuRm9yZWNhc3RpbmdcZUNSTVxDYWxsTGlzdEV4cG9ydC5hc3B4?=
X-Powered-By: ASP.NET
Date: Fri, 06 Dec 2013 10:11:13 GMT
Content-Length: 34590
from the new method, download dosent start.
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 316928
Content-Type: application/vnd.ms-excel; charset=utf-8
Content-Encoding: UTF-8
Expires: -1
Server: Microsoft-IIS/8.0
Content-Disposition: attachment; filename=CallList_2013-12-06.xls; charset=utf-8
Charset: UTF-8
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcZGV2XHRmc1xrYmFzcnZcZUdhaW4uV2Vic2l0ZXMuRm9yZWNhc3RpbmdcYXBpXFByaW50XENhbGxpbmdMaXN0QnlDb21wYW55T3JDdXNvdG1lcklk?=
X-Powered-By: ASP.NET
Date: Fri, 06 Dec 2013 11:04:49 GMT
UPDATE added Method where i return the result
the ByteResult class only contains byte[], contentLength, contentType and filename
protected HttpResponseMessage ByteResult(ByteResult result)
{
try
{
var responseStream = new MemoryStream();
var buffer = result.Data;
responseStream.Write(buffer, 0, Convert.ToInt32(result.ContentLenght));
// No Range header. Return the complete file.
responseStream.Position = 0;
var response = new HttpResponseMessage
{
StatusCode = HttpStatusCode.OK,
Content = new StreamContent(responseStream)
};
response.Content.Headers.Add("Content-Disposition", "attchment; filename=" + HttpUtility.UrlEncode(result.Name, Encoding.UTF8));
response.Content.Headers.Add("Content-Type", result.ContentType );
response.Content.Headers.Add("Content-Description", "File Download");
response.Content.Headers.Add("Content-Encoding", "UTF-8");
response.Content.Headers.Add("Charset", "UTF-8");
response.Content.Headers.Expires = new DateTimeOffset(DateTime.Now);
return response;
}
catch (IOException ioex)
{
return ErrorResult(ioex, "Unknown IO Error", HttpStatusCode.InternalServerError);
}
catch (Exception ex)
{
return ErrorResult(ex, "Unknown Error", HttpStatusCode.InternalServerError);
}
}

I'd try double checking the MIME Type mappings on the client that the excel file is being downloaded to.
Also, if you change the content type in the response to application/octet-stream the client should just ask if you if you want to save the file - if the saved file is then corrupt look further into the encoding of the file.
Also look in Fiddler to ensure that the response is terminated correctly, I've previously seen files sent correctly, but then other messages tagged onto the end of the response stream due to server errors - in my case because a view didn't exist when using Monorail - so we ended up with an excel spreadsheet followed by 500 error text.
HTH,
Nick