Zutaten: Ziegenkäse, Frühstücksbacon und je nach Geschmack Trockenfrüchte (Pflaumen/Datteln) und Basilikum. (Gibt’s alles z.B. bei Netto)

Den Ziegenkäse (und evtl. Trockenfrüchte/Basilikum) einfach in den Bacon einwickeln und ohne zusätzliches Fett in die Pfanne.

Von allen Seiten gleichmäßig anbraten und voila:

‘n Guten.

Following Problem:

I have a Linux System on which I want to execute a BASH Script over Telnet. So I used the help of the Inetd Service.

First I declared my own Service in /etc/services by adding the following line:

# Local services
myservice         4321/tcp

Then I make my Script known to inetd by adding the following Line to /etc/inetd.conf

myservice stream tcp nowait root /home/me/script.sh

and restart the service.

‘Til here it’s simple. But now comes the catch you will experience when you execute your script over the telnet connection. Since you’re not in a terminal enviroment, in which you’re when you use telnetd or sshd, there’s a different handling of Line endings. In a normal Unix Terminal a line end is represented by a simple \n aka. LF (Line Feed) aka 0x0A. But in TCP, as it’s used when you use inetd \r\n aka CR LF (Carriage Return, Line Feed) aka 0x0d 0x0a is used.

So what happens, is that if you read input into a variable the string is parsed until a \n occurs. So the \r is still in your string and fucks up most of your commands using this string. There are at least 2 Methods to get rid of this. The one i prefer is this one:

read foo
foo=`echo $foo | tr -d '\r'`

Which just kills all the \r in the string. It also enables you to use the script in terminal and non-terminal enviroments.  Second method would be to just cut off the last char. By which the Script becomes unusable in the normal shell.

read foo
foo=${foo:0:${#foo}-1}

In the output direction you’ll notice another effect of this behaviour. Since there is a \r expected where none is send you’ll experience this nice stair effect. So you have to replace the \n in all your output with \r\n to get this right. Most telnet clients like Putty on Windows have an option (Terminal -> “Implicit CR on LF”) to do this automatically. It’s  your choice how you solve this.

Please Leave a comment if this was of any use to you.

Sources:

Bash Webserver using Inetd – http://www.debian-administration.org/article/A_web_server_in_a_shell_script

Discussion Thread with most of the solution – http://www.mail-archive.com/debian-user-german@lists.debian.org/msg41768.html

Another Thread on the Topic – http://unix.derkeiler.com/Newsgroups/comp.unix.shell/2003-08/1337.html

Das Log des WebDAV Server sagte dazu nichts. Im Proxy allerdings tauchten folgende Zeilen auf:

[error] proxy: Chunked Transfer-Encoding is not supported
[error] [client 123.123.123.123] Handler for proxy-server returned invalid result code 22


Nach längerer Google Suche bin ich nun auf diese Seite gestoßen: http://www.atnan.com/2008/10/16/memory-issues-with-nsmutableurlrequest-s-sethttpbody-method-in-iphoneos-2-1. Auch wenn es da ums iPhone geht scheint das Problem das gleiche zu sein.

Große Dateien (Tritt aber auch schon bei 12k auf) werden auf sog. Chunks aufgeteilt. Dies wird im Header der http Pakete entsprechend gekennzeichnet. Anscheinend machen das die meisten Clients mit dem schlüsselwort “chunked”, Apple macht dies aber durch das Wort “Chunked”. (Man beachte die Groß-/Kleinschreibung). mod_proxy scheint im Gegensatz zu den meisten WebDAV Servern damit überfordert zu sein.

Die Lösung brachte nun die folgende Zeile in der Config des mod_proxy Hosts:

RequestHeader edit Transfer-Encoding Chunked chunked early

mod_proxy bekommt nun das Encoding als “chunked” und alles ist gut.

Es werden bei GMail über POP3 also im Normalfall nur die neuen Mails angeboten. Will man diese mit mehreren Clients Mails abrufen muss der Nutzername folgendermaßen aussehen: recent:nutzername@googlemail.com

Dadurch werden die Mails der letzten 30 Tage dem Client angeboten und dieser entscheidet welche Mails er herunterläd, also das sonst normale Verhalten. Man muss natürlich seinem Client dann auch noch sagen dass er die Mails auf dem Server belässt.

Ob dieses Verhalten rfc-konform ist wage ich zu bezweifeln, macht aber bei der möglichen Größe von GMail-Postfächern durchaus Sinn.