After page loading has finished the number of free bytes left for page attributes is logged. It turns out that "usual" pages tend to get along with ~800 bytes while i.e. the Google search pages use all of the 2000 bytes of page attribute memory allocated by default (because of the long URLs with many parameters). So it seems that reducing this default isn't exactly the best way to reduce memory consumption...
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
When the client has already called webclient_close() it doesn't expect to have webclient_datahandler(NULL, 0) called just because the connection was closed by the server "at the same time". Rather it expects to always have webclient_closed() called.
Calling webclient_datahandler(NULL, 0) instead of webclient_closed() means that the web browser shows "Done" in the status line instead of "Stopped". So the user is mislead to think that he has already seen all of the page.
Note: webclient_close() is called by the client during newdata() so the already existing check for WEBCLIENT_STATE_CLOSE further above doesn't help.
../..//apps/er-coap/er-coap-observe.c:237:15: warning: unused variable
‘content’ [-Wunused-variable]
This was caused by a buffer that was declared, but used only in
commented out code.
The variable was moved to the commented out block.
The block was surrounded by an #if 0 ... #endif to make it easier to
uncomment.
Everything still compiles with the code in question uncommented.
When a client sends a CoAP request with no block2 size,
the default one would be set to REST_MAX_CHUNK_SIZE.
However, this is not guaranteed to be a power of 2.
This can lead to clients receiving a bigger payload than expected as
part of the header, and ending up with duplicated content.
Setting the default to COAP_MAX_BLOCK_SIZE,
which is guaranteed to be a power of 2, fixes this.
The default Telnetd idle timeout of 30 seconds seems somewhat short. Best to have it user-configurable (incl. the option to turn it off with an config value of 0).
In order to have the wget command make some sense the write command should be present too.
- On the Apple][ reduction of the MTU seems to gain just enough RAM to have the (rather heavy-weight) full-blown C library file I/O working.
- On the C128 there's way too little RAM so there's no wget command but only the file commands.
- On the CBMs a dummy lseek() was necessary to have the read command link.
Forms with multiple submit buttons are rather rare but nevertheless the most popular web page (www.google.com) contains one with the two submit buttons "Google Search" and "I'm Feeling Lucky". So we want to support that - incl. the usual feature to the interpret first button as default button used when the user presses the ENTER key.
Script code may contain a '<' as part of a equation. We erroneously interpreted that as start of a tag. Now we check for the very next char to be a '/' as the only tag allowed is the </SCRIPT> tag.
When using the 'down' button on a certain number of lines curently displayed at the bottom of the screen is redisplayed at the top of the screen. Given our usually small screen size and often large pages requiring many 'down' operations the number 'four' seems too generous so lets reduce it to 'two'.
- The wraparound handling when using the history with the 'back' button is actually depending on history_last being unsigned (which is the default for cc65) so define it explicitly as unsigned to make it work on other targets too.
- As there's no 'forward' button it doesn't make sense to keep history entries after using them with the 'back' button. Clearing them on use on the other hand avoids an "infinite history".
Although we for sure don't support HTTPS we need to recognize it. Nowadays it has become pretty usual to redirect HTTP URLs to HTTPS URLs in order to force privacy (thanks, NSA !). So far our redirection handler didn't recognize an HTTPS URL as abslute URLs and therefore appended it to the curent URL. This led to an endless redirection loop. Now we recognize the HTTPS redirection and generate a minimal document on the fly to inform the user of (for us unrachable) the redirection target.
HTML links with HTTPS URLs are treated just like fragment-only links meaning that they get simply completely ignored.
