ARMweb serving other files types

[YahooArchive]

You are correct on the
and added this
info.

With your changes I don't need the post processor and will add all the extra
stuff.

I am working on breaking up the files because every time I call it
adds 500-800ms to the file load, and i am hitting the 1450byte limit.

As for removing the CR-LF I also tried

_______START OF FILE_____________
<0x01 Actual Char>Content-Type:text/xml


..Rest of File


And it did not work

Can you upload a sample file that works on your end

[YahooArchive]

I found Notepad in System 7 won't let you put a $01 character into a file, it
converts in to a ? before saving.

There's a hex edit utility from sourceforge I downloaded to set that character.
Frhed

But I'd still like to know what program are you using that wants to see the xml
content type in the HTTP response?

As windows tries to keep you from entering that character we'll probably change
the syntax if this feature really is required. One option would be to look at
the first non-blank character in the served html / xml file and if its not a <
treat it as part of the HTTP response. But we're still not convinced this is a
necessary feature.

[YahooArchive]

The XML Processor, Crome, and Firefox all choked on the XML when is was served
up with an .HTM ext. So the content type was a requirement.

However now that you added .xml as a supported ext you can drop the feature if
it is an issue to implement.

There are alot of cool response headers but for a basic device like this you
could do without.

I actually moved all the complex we stuff to a web server and just use the
device as a XML I/O Device for the PHP pages.

The device is very slow on the web side when using multiple to plug
data into a web page, It seams to add 500-800ms for each instance. My file that
used 4 of these took 4000-4500ms to load. I compacted and get within the buffer
limit and use on 1 now and it only takes 500-600ms to load now.

Static pages are pretty quick though.

[YahooArchive]

IMHO, it's definitely a necessary feature. There are countless
apps/services/agents that depend on content type, but it goes way beyond just
that one header.

One example, cache-control, which would've saved me a bunch of work. My code
has to append a dummy parameter to each request URI, with the value being the 32
bit representation of date/time (used by ECMA/Javascript's Date object) to avoid
getting a cached response.

Browser cache also forced me to a more complex AJAX-style model, where my HTML
document's script uses XMLHTTPRequest to send commands and retrieve status
to/from the ARMWeb.

Again, that's but one example. The number of potential use cases that would
need to work-around the lack of ability to specify response headers could be
infinite.


-MM

[YahooArchive]

>
> IMHO, it's definitely a necessary feature. There are countless
apps/services/agents that depend on content type, but it goes way beyond just
that one header.
>

We will add this feature to the next firmware that will go out later this week.

But cache control is a hot topic on the web, and not all browsers do it the same
way, even differing in revisions. We found adding another < HEAD > at the end
of the page solved it in most cases. For more info google html cacheing for
articles like

http://www.htmlgoodies.com/beyond/refer ... hp/3472881

[YahooArchive]

A lot of activity here in the last week, so here's the executive summary

XML support has been added

HTTP response headers can be controlled by the htm/xml/html file, by having the
first character be non-space and not a < The code up to the next blank line in
this case will be sent out with the
HTTP/1.0 200 OK
(this will be part of the next release 7.47 later this week)

A bug with large strings in has been fixed.

ftp is slow, and will remain that way as the NXP IAP routines are pretty slow.
You may encounter errors if you try to put more than 1 file at a time, be
patient and make sure the last operation has completed before doing another.
Deletes are even slower.

The current firmware echoes to the USB port via a serial link.
This can be a lot of overhead, but it is useful for debug. The next firmware
will disable this echoing when AUTORUN is turned on, except in the case of an
error, which will get echoed to the USB debug port.

[YahooArchive]

Could you add a command DEBUG and if this is in your code it runs as it
currently does dumping the info but if the command is missing it would run the
new way you described.

Also I am still have the issue whith the new firmware where I can no longer
access the controls when

#1> Security ON
#2> My program has executed and End command
#3> My program is no longer running.

All I get is the armweb page but the run and config tabs do not work. They only
way to modify the config it to wipe the device back to factory and reload all
items.

Prev to the last few Firmwares when you presed stop or end you could make
changes, once the program started it would lock out like you desribed.

[YahooArchive]

AutoRun should be the last thing you enable once your program is
debugged. If you're still updating files or code, AutoRun should be off.

To get web page service with all that has to be true is that your
program is running not AutoRun set.

[YahooArchive]

> I see the exp firmware posted, can you give us the new fetures spelled out on
how to use so we can test.
>
> What is the propper way to post a header now?

An experimental version was posted, don't know why but my message was not.

Anyway-
We've tested-
UART echoing of compile/html output from BASIC is now disabled when the
security/autorun is set

If the user program hits an END, then security/autorun is disabled until the
next reset (that means that the controls page, program loading and ftp are all
enabled)

Untested-
for xml, and html
if the first non-blank character is not a <
then those lines up to the first blank one are sent out as an http response
following the
HTTP 1.0 OK

[YahooArchive]

FYI

Adding the 0x01 before and a blank space works great.

I look foward to the easier version as it is a pain in Windows to add that 0x01.