Issues Recreating Http Headers from an older application - axios

I am having an issue uploading files to my server on a frontend rewrite I am working on.
I am getting an error response 500 "Premature end of script headers:" I have my headers recreated almost exactly the same as the legacy web app I am trying to recreate with two exceptions.
Backstory: I am recreating a Flash web application in Vue.js. I am using the exact same back end intact, it is Perl, cgi scripts, generally, I am able to use axios to talk to the backend scripts no problem.
Current Flash Frontend: When I upload a file with the current flash app my header looks like this.
Note the highlighted text at the bottom.
Replacement Vue Frontend: I see a couple differences with my new header, I don't have the Content-Type: application/octet-stream bit directly underneath the filedata part of the header. And the end of the header is "--" which is the convention, I am guessing the old application used some outdated header ending I can't find and doesn't know how to handle mine. Please help I could not find anything on the Google. I also note the new header has "WebKitFormBoundarys" not sure if that could cause an issue with some old header standards or something.

Issues were related to outdated Perl packages, once they were upgraded to backend script recognized the header correctly.

Related

SLIM API - Offer Files to Download

I am using Slim API for my Project. I want to offer Files for Download (Mostly PDF files). I found several Ways sending out a public link to the file, which i dont want. I also found an Middleware for the Version 2.4 of Slim, but I am using 3.x.
I just want to access the Route e.g. /downloads/version/2183
And the a Downlod with this certain File ID should start. I have a Path to the File on the Server in a variable available.
The Basic Idea behind is different restrictions, which user can download the file - but i can do that myself - the problem where I am stuck is, how to bring the Download over the Route to the Clients Browser
Does anyone know how to achieve this?
Cheers,
Niklas
This is actually very easy.
Set the Proper Headers for the file on the Response Object
Read the contents of the file into the body of the Response Object
$app->get('/my/file', function ($req, $res, $args) {
return $res->withHeader('Content-Type', 'application/octet-stream')
->withHeader('Content-Disposition', 'attachment')
->write(file_get_contents("file.txt"));
});

Setting the Expiry Headers for JS/Images

Please help to set the Expiry Header for files like JS/Images/CSS
Server : Linux
App Server : Jboss
I was getting some examples in internet to achieve similar thing using .htaccess files, but it not clear.
You can do that within an application by using a custom filter, like this.
But you did not explain the actual problem you are trying to solve. Your question sounds pretty unusual, so chances are high that what you really need is something completely different. You mention .htaccess file, and this means you have a web server, likely Apache, along with JBoss. Static contents (files like .css, .js, etc.) should normally be served by that server, not JBoss. Then, it's not JBoss that should set HTTP headers for them. Here you can find an explanation how it should be done in Apache.

How to find out the source of a request (in chrome dev tools)?

I have a weird network request in my page, which refers to JavaScript files, which I removed from every html file earlier. Cache is cleared and there is no single reference to be found in the source html and the JavaScript files. For fixing that and also out of general curiosity I would like to know if there is a simple way to find out where a request was triggered, preferably using the chrome-devtools.
Update:
Thanks to jaredwilli I found the initator column under the network-tab. However this only shows Other. What I would like to know, is the (html or javascript) file where those Requests have been triggered.
On the Network panel, you can determine what the initiator of a request was by viewing the Initiator column. It gives you the file, line number and type of resource it was, either Script or something else.

iOS Web App - how to deal with overzealous app caching?

I've been developing a pretty complicated HTML5 web app for the past month. Last night my iPhone suddenly decided to cache all JS, CSS, and images and not load any updated copies. This happened on my partner's iPhone too, so I'm going to assume it's affecting all users of our app.
Needless to say, clearing the browser cache, deleting the web app, restarting the phone, & restarting the wireless connection do nothing to fix the problem.
Removing <meta name="apple-mobile-web-app-capable" content="yes"> solves the problem, but creates a new problem since we need the app to run like...an app.
We're not going to go around appending the old trick ?number to the end of all our scripts, stylesheets, and images either. That's ridiculous. Also -- if we were to implement something like this, it would have to be some sort of dynamic JS implementation. Our app is one HTML page that loads most scripts, and additional pages are AJAXed in, additional data is also obtained via AJAX. I guess this could be done, but I'm hoping for a more elegant solution. Ya know, I feel like I shouldn't have to do anything since this all worked without a hitch for an entire month.
Using the cache-control, expires, and pragma <meta> tags doesn't do us any good either, as this is purely an iOS web app problem. Caching works normally in mobile Safari, mobile Chrome, and all desktop browsers. It appears that iOS has a separate cache for apps, including web apps, that the user can not clear.
It seems that many SO users have encountered this problem, but I can't find any satisfactory solutions. Has anyone out there in a similar situation solved this problem? Could I use a manifest file to specify not to cache several files? It seems like manifest files are used to do the opposite.
For what it's worth, and it's not a perfect solution, we had to settle with appending query strings. I've written a shell script to make this and a few other tasks bit more automated, you can look at the source on GitHub. A few details:
It's designed for JS but can easily be edited to handle CSS too.
It takes all files listed in script_order.txt and compiles them with Google's Closure Compiler
Groups them into chunks under 25kb when possible (iPhone won't cache anything over 25kb pre-gzip, although apparently this extends only to browsers and not standalone webapps)
Outputs a PHP file with <script> tags that have a ?v=timestamp appended to the script filenames. If you're working with static HTML and can't include a PHP file, you could rewrite the output to append the script tags to your index.html file.
Another pretty hacky solution would be to save your JS/CSS with a .php file extension, and in those files set the headers to something like this:
<?php
header("content-type: application/javascript");
header('Cache-Control: no-cache');
header('Pragma: no-cache');
?>
window.alert('hello world');
EDIT:
Setting the date to 2, 3 or 4 days in the future, start the app from homescreen and then set the date back to normal also can do the trick.

iPhone RSS Reader -- parseXML won't Load some XML feeds

I am using the SIMPLE RSS reading example found at http://theappleblog.com/2008/08/04/tutorial-build-a-simple-rss-reader-for-iphone/
It uses parseXML to load the RSS feeds.
Here is the problem I am having. For the following RSS feed example, I am having trouble getting it to load the feed. Comes up with an error that it cannot connect. However on my Mac RSS Reader it works fine, so I know the link is good.
Any ideas on why it cannot load this particular feed but it can load others fine?
http://www.okstate.com/rss.dbml?db_oem_id=200&media=news
Thanks.
I've just released an open source RSS/Atom Parser for iPhone and hopefully it might be of some use.
I'd love to hear your thoughts on it too!
In my experience, HTML markup causes an RSS parser to fail in most cases. I've experienced a problem like this with a lot of parser classes I've come across (in search of the ultimate one, which I didn't find)
My guess is that entities such as
&#39;s
are responsible for your crash. That was usually the case with my crashes. This also lead to my decision to create a 'proxy server' to pre-parse the XML before sending it to the iPhone (which gives me the advantage of caching, scaling, and some other stuff). I do believe there are solid solutions out there, but is always difficult writing a parser for so many RSS implementations.
P.S: W3C validates this feed as 'valid', so it really is 'our' problem..
Your problem could lie with:
Unicode characters (i.e. I see some o's with two dots above them in the feed)
The code you have doesn't respect CDATA sections correctly
To find out which is the case, save the feed file to your local disk and load it via your code to make sure the error happens.
Do a binary search on the file to find out if a particular RSS entry is causing the problem (i.e. remove all but the first rss entry and see if the problem exists. If it does, then the problem is there, if it doesn't put half the rss entries back in the file and repeat)
I've been experiencing a similar issue. I haven't yet pinned down the answer, but I've noticed that RSS 2 tends to parse more successfully than the rest.
There are many RSS feeds that contain invalid XML, usually because they were hacked together on the server side using HTML templates by somebody who didn't understand XML. I've seen improperly escaped (or non-escaped) HTML post contents, missing close tags, badly nested tags, and so on.
If you want to be able to parse arbitrary feeds, you have to clean up bad XML. The usual way is to use the "htmlTidy" library, which is included in the OS. This can clean up XML as well as HTML.
This example you're following uses NSXMLParser -- I have no idea why. It's a lower-level API and it doesn't support tidying. I would suggest using NSXMLDocument instead. There's a flag in that API that will tell it to use tidy when parsing the XML. This API also returns you the XML as a handy tree of elements that's easy to work with.