The Azure WAF can be configured to check the maximum size of a request like this:
Anyway, besides having this configuration, any time we upload a file the WAF considers it as a "not file upload operation" and returns 413 "Request entity too large" if the file exceeds 128 Kb.
We are sending the POST request with what we think are the right headers:
Content-disposition: attachment; filename="testImage.jpg"
Content-Length: 2456088
Content-Type: image/jpeg
But it does not make a difference. Any idea why the WAF does not see this is a file upload and applies the Max file upload check instead of the Max request body size limit?
After several conversations with Microsoft we found that the WAF considers only file attachments if they are sent using multipart/form-data
If you send it this way the WAF will understand it is a file and thus will apply the limits configured for files instead than for bodies.
There is no other way to send files supported by the WAF for now.
From documentation:
Only requests with Content-Type of multipart/form-data are considered
for file uploads. For content to be considered as a file upload, it
has to be a part of a multipart form with a filename header. For all
other content types, the request body size limit applies.
Please note that filename header also needs to be present in request for WAF to consider it as file upload.
Related
I try to upload gif to AWS S3. URL is presigned. For presign I use Vapor for sending image it happens from React.
Here docs says: https://soto.codes/2020/12/presigned-urls.html
If you want to include some headers values with the URL you have to include the headers while signing it and the client will be required to include exactly the same headers when they use the URL.
but image/gif is sent at presign. In the return of presign I see X-Amz-SignedHeaders: content-type%3Bhost%3Bx-amz-acl.
Seems presign did his part.
Then the content upload, with PUT has also has the Content-Type: image/gif
Then what is wrong. Why S3 does not have the type?
No type here:
Just realised you are looking at the wrong thing. Scroll further down on the aws console page until you find the metadata section. You can also test this by running a get on the object and see what content-type is returned
As i understand Accept-Encoding in header compresses the data retrieved and decompressed in the client(postman). Is it possible to avoid decompression(ie as a zip file)
I have the Accept-Encoding=gzip, deflate, br in the header for a GET request i run from postman. the actual response is a csv file and the content of csv is shown in response. How do I get the response as a zip file when called from postman. (without modifying the API to compress). I want it zipped for reducing size when again passing the file.
Content-Dispoistion:attachment also not helps
I'm building a web server as an exercise. When I receive a raw request, it gets parsed into an simple syntax tree, and a response is built by evaluating this tree. My question this: When sending an HTTP Response, does the Content-Type field get set by taking the file extension of the requested resource and looking it up in a dictionary of MIME-types? A good example would be the anatomy of how the response for a favicon.ico is built. Any insight into this would be most helpful. Thanks.
By default, web server looks into file extension and select what kind of Content Type it should interpret the file as. However, server-side scripting can send custom header ( e.g. header() function of PHP ) to override the settings . For example, a JPEG can be interpreted as PNG if you send Content Type as image/png to web server with the following code:
header('Content-Type: image/png');
For non-file requests, the web server looks into custom header directly.
Web server maps extension with MIME type. As you tag apache, Apache uses AddType directive to identify file's MIME type, while IIS and other web servers have similar settings .
We have uploaded an mp4 video file into our Magnolia DMS, which fails to play on Safari (Mac/iPad). Investigation shows that the Content-Type returned by Magnolia is "application/octet-stream" for the request. When serving the file through Tomcat directly, the correct Content-Type "video/mp4" is returned and video playback works.
How can we configure the content-type to be returned in Magnolia?
We know the content-type is a function of the request (e.g. if we add ".jpg" to the URL the type returned is "image/jpeg"), but couldn't use this knowledge to come up with a solution.
Update:
We found the MIME configuration and could change the Content-Type for "mp4" to "video/mp4". However, the Content-Type returned by Magnolia is now
Content-Type: video/mp4;charset=UTF-8
while the correct, working Content-Type returned for files hosted by Tomcat is
Content-Type: video/mp4
Is it possible to make Magnolia not append any charset info to the Content-Type?
Glad you found the MIME configuration OK.
Both the MIME type and the character encoding are set in ContentTypeFilter.java and MIMEMapping.java. You can specify a charset for a MIME type yourself by including it in the mime-type definition. (E.g. "video/mp4;charset=UTF-8".)
If you don't include one, however, Magnolia automatically assigns the default (in this case, UTF-8). If you want to change this behavior, you'd need to tweak the source code.
Out of curiosity, is the charset causing you any trouble, or are you just trying to get Magnolia to match what Tomcat does by default?
Can we remove response headers when we are accessing images stored on Amazon S3?
By default it is giving the following headers:
x-amz-id-2:
x-amz-request-id:
Server:
By default it is giving amazon related values for these headers. Is there any way to remove headers?
Not without proxying the requests through some software you control that can strip the headers. Pretty sure Amazon has no user setting for that.