I have noticed that my yesod site does not respond with Content-Length header.
I have tried to add it with addHeader (in the Handler) with no result.
I am sure that I am missing something very fundamental, but do not see it.
My handlers are Handler Html handlers. I have suceeded adding a custom header using addHeader right before defaultLayout...
Content-Length is a special header, in the sense that its presence when incorrect will mess up your response. A number of different components will end up stripping it out. My guess in this case is that your response is being GZIP compressed, which necessarily removes the content-length header.
Related
I am facing the following problem:
when sending SAAJ requests with MTOM attachments , the original request body looks like this
<soapenv:Body>
<ns1:UploadMsgRq>
<ns2:Attachment><xop:Include href="cid:testfile.xml" xmlns:xop="http://www.w3.org/2004/08/xop/include"/></ns2:Attachment>
</ns1:UploadMsgRq>
</soapenv:Body>>
The attachment tag value get transformed to
<ns2:Attachment>PHN0YXJ0Pkdhc3Nlcjwvc3RhcnQ+</ns2:Attachment>
which is the base64 value of my attachments, I don't want this to happen, specially that the attachment is already added as MTOM part.
Also the same code is working as desired on JBOSS.
Is there a special handling that I should do n websphere?
Here is the solutions that I've found:
Drop the SAAJ client and generate a client from the WSDL, this will automatically keep the XOP:Include as is.
Keep the SAAJ Client but for the include tag you must do one of the following a) make sure that the include tag has a space in its content <xop:Include href="cid:testfile.xml" xmlns:xop="http://www.w3.org/2004/08/xop/include"> </xop:Include> or b) add it dynamically using addChildElement. For both a and b your handler -if any- shouldn't call context.getMessage() or it will generate the bas64 again.
I am writing code that needs to respond to html redirections using the Location header. Mostly it works find, however, in some cases the header simply says to redirect to some resource, presumably on the same host, for example
Location: main.html
In other cases it will simply provide a new domain, for example
Location: abc.example.com
Now, how can I tell whether the redirection needs the existing host domain prefixed to the given partial URL without having to check all possible top-level domains in the suffix of the string? The only thing I can think to do is simply try one resultant URL and, if it fails, attempt the other one.
Has anyone got a clever solution or come across this problem before?
According to section 14.30 of RFC 2616 the Location: header must specify an absoluteURI. RFC 2616 borrows (see section 3.2.1) the specification of the absoluteURI from RFC 2396, and section 3 of RFC 2396 makes it clear that an absoluteURI is, well, an absolute URI.
Any other kind of an URI like the sample responses you're getting, violates RFC 2616. Those responses are invalid, and there is no valid interpretation of them.
First, it does not appear that you're getting valid Location headers. Location headers must include either absolute URLs (that start with a specifier (e.g. "http:") or relative URLs (that start with either "//hostname" or "/" (for paths). (see https://en.wikipedia.org/wiki/HTTP_location and https://www.rfc-editor.org/rfc/rfc3986#section-4.2).
That being said, if you're stuck with a server sending you broken Location headers, you could do some heuristics to try to guess whether it starts with a hostname or not. Obvious ones include whether it ends with common file format extensions (e.g. .html, .txt, .pdf) or common TLD suffixes (e.g. .com, .org, .net). This isn't fool-proof, as with the explosion of TLDs, there's likely to be overlap with file extensions, and in theory, a file can end in anything (as, for instance, some end with .com). But it would probably get you 98% of the way there - and then you could just try both and see which gives you an answer.
There's always the possibility that both give you an answer, in which case it's just a Hard Problem(tm). That's why the specification is what it is - to avoid this kind of ambiguity.
I need to perform some logic based on cucsom headers. I'm using Chrome's postman to add the headers.
But it seems like I can only add them when the header name doesn't have a '_'
Is there any reason for this ?
ideally i would like to add a header somthing like 'MY_HEADER' and access it via request.META['MY_HEADER'], right now I'm adding it as 'MYHEADER' and accessing it via request.META['MYHEADER']
Thank you vanadium23, Turns out Nginx was making changes. Full answer here Why underscores are forbidden in HTTP header names
I have a view that protects certain sensitive files from public download, using nginx' X-Accel-Redirect header. My URL looks like this:
url(r'^dl/f/(?P<pk>\d+)/(?P<filename>[^/]+)$', 'file_download.views.download', name='download-filename'),
pk is the primary key of the file object in the database, filename is the file name, which matches anything but the forward slash. It's mainly there so that the browser knows the file name in case the user wants to save it. Note that there is no terminal slash.
When I open a matching URL in the browser, Django nevertheless redirects it to the same URL with a slash appended. The file is displayed in the browser (it's a PDF), but if I want to save it, the browser suggests a generic "download.pdf" instead of the file name.
I don't want to disable APPEND_SLASH for the general case, but can I somehow get around it for this single case?
/edit: unfortunately, I can't use the Content-Disposition: attachment header, because all other files are served without that header as well, and consistent behavior for both protected and unprotected files is a requirement.
I don't know where/if it's in the docs, but I believe that putting an extension into the URL will prevent this behavior, so instead of some-filename/, use some-filename.pdf (and alter the urlpattern accordingly, of course).
However, I'm not entirely sure about that. Really, your primary problem seems to be that the download's filename is not set properly, and that can be fixed without messing with the URLs one way or another. Just store the response instead of returning it immediately, and then alter the Content-Disposition header:
response = HttpResponse(mimetype='application/pdf')
response['Content-Disposition'] = 'attachment; filename=somefilename.pdf'
UPDATE
Concerning the two points in your comment:
The urlpattern can accept a wildcard extension \.\w{3,4}.
'attachment' is what forces a download. 'inline' can be used to make the file load in the browser. The filename can be asserted either way.
I'm using lib-cURL as a HTTP client to retrieve various pages (can be any URL for that matter).
Usually the data comes as a UTF-8 string and then I just call "MultiByteToWideChar" and it works well.
However, some web-pages still use code-page encoding and I see gibberish if i try to convert those pages to UTF-8.
Is there an easy way to retrieve the code page from the data? or I'll have to scan it manually (for "encoding=") and then translate it accordingly.
If so, how do i get the code-page id from name (Code Page Identifiers)?
Thanks,
Omer
There are several location where a document can state its encoding:
the Content-Type HTTP header
the (optional) XML declaration
the Content-Type meta tag inside the document header
for HTML5 documents the charset meta tag.
There are probably even more I've forgotten.
In the end, detecting the actual encoding is rather hard. You really shouldn't do this yourself but use high-level libraries for retrieving and parsing HTML content. I'm sure they are available even for C++, even if they have to be thiefed from the a browser environment. :)
I used DetectInputCodepage in IMultiLanguage2 interface and it worked great !