HTTP GET auswerten

[Hans M. (hans_maulwurf)]

Hallo zusammen,

ich will über die Homepage des AVR verschiedene werte aus dem EEPROM 
laden und dort anzeigen.
Das ganze will ich über HTTP GET realisieren.
.)auf der homepage wird nach auswahl ein GET Response gesendet(OUT=X)
.)nun will ich im httpd den Wert von X herausfiltern und je nach wert 
den EEPROM auslesen.

Kann mir wer dabei helfen?

[Karl H. (kbuchegg)]

Hans Maulwurf schrieb:
> Hallo zusammen,
>
> ich will über die Homepage des AVR

Wer oder was ist 'die Homepage des AVR'.
Ein AVR ist ja nicht a priori ein Web-Server. Da muss ja ein Programm 
laufen, welches einen Web Server realisiert.

[Hans M. (hans_maulwurf)]

Karl heinz Buchegger schrieb:
> Hans Maulwurf schrieb:
>> Hallo zusammen,
>>
>> ich will über die Homepage des AVR
>
> Wer oder was ist 'die Homepage des AVR'.
> Ein AVR ist ja nicht a priori ein Web-Server. Da muss ja ein Programm
> laufen, welches einen Web Server realisiert.

vl habe ich den rest ja schon ;)

[Karl H. (kbuchegg)]

Hans Maulwurf schrieb:
> Karl heinz Buchegger schrieb:
>> Hans Maulwurf schrieb:
>>> Hallo zusammen,
>>>
>>> ich will über die Homepage des AVR
>>
>> Wer oder was ist 'die Homepage des AVR'.
>> Ein AVR ist ja nicht a priori ein Web-Server. Da muss ja ein Programm
>> laufen, welches einen Web Server realisiert.
>
> vl habe ich den rest ja schon ;)

Aber von diesem Rest hängt es ab, wie du diesen Rest verändern musst 
(wenn überhaupt) damit ein bestimmter GET Request von diesem Rest so 
verstanden wird, dass der Rest eine EEPROM Speicherzelle ausliest´und 
zurückliefert.

Deine Frage ist ungefähr so sinnvoll wie:
Ich möchte gerne meine Kofferraumbeleuchtung automatisieren. Welche 
Farbe hat das Kabel, an das ich mich anhängen muss und wo finde ich es?

Ohne zumindest der Nennung der Automarke wird es da wohl keine so 
richtige sinnvolle Antwort geben können.

Lieber in einer Fragestellung ein paar Details anführen, die keiner 
braucht als zuwenig Info als das ein Helfer damit etwas anfangen könnte.

[Hans M. (hans_maulwurf)]

ich will eig nur wissen wie man einen GET Request ausliest, muss ich nur 
HTTP beachten oder auch TCP?

[A.N. (Gast)]

Hans Maulwurf schrieb:
> ich will eig nur wissen wie man einen GET Request ausliest

Das macht der Rest doch schon, sonst wäre es ja kein Webserver.
Da Du den Rest ja hast ... verstehe ich Dein Problem nicht.

[Björn R. (sushi)]

Geht in php z.B. so

<?php

$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);

if(!isset($socket))
  echo('Socket konnte nicht erzeugt werden.<br>');
if(!socket_connect($socket, gethostbyname('youtube.com'), 80))
  echo('Die Verbindung zum Youtube-Server konnte nicht hergestellt werden.<br>');
else{
  $buffer = "GET http://gdata.youtube.com/feeds/api/users/username/uploads HTTP/1.0\n\n";
  if(!socket_send($socket, $buffer, strlen($buffer), 0))
    echo('GET-Request konnte nicht gesendet werden.<br>');
  else{ 
    
    do
    {
      
      $count = socket_recv($socket, $buffer, 1024, 0);
      if($count==false)
      {
        echo('<br><br>Verbindung unterbrochen!<br>');
        echo(socket_strerror(socket_last_error()));
        break;
      }

      $buffer2.=$buffer;
    }while($count>0);  
  }
}
socket_close($socket);


?>

Die Antwort auf den GET-Request liegt danach in $buffer2. in dem 
Beispiel werden alle Youtube Videos des users 'username' 
zurückgeliefert. Den host und die Adresse ersetzt du natürlich durch 
das, was du haben willst. Ach ja, am Anfang hängt noch der HTTP-header 
dran.

LG, Björn

[Karl H. (kbuchegg)]

Tip:
Wenn auf eine Anfrage keine vernünftigen Antworten in einem angemessenen 
Zeitraum kommen, dann nochmal die Frage durchlesen. Dabei hilft es sehr, 
wenn man sich blöd stellt und sich fragt ob man die Frage verstehen 
würde, wenn man sie das erste mal sieht und keine Ahnung hat, woran der 
Fragesteller arbeitet. Auch hilft es sich zu fragen, ob in der 
Fragestellung irgendwelche Annahmen über Details getroffen werden, die 
nur der Fragesteller kennt und sonst niemand.

Und noch ein Tip:
Du hast Pech. Als Moderator kann ich auch die Postings sehen, die du 
selbst wieder gelöscht hast.

Und tschüß

[Jörg W. (dl8dtl) (Moderator)]

Björn R. schrieb:
> Die Antwort auf den GET-Request liegt danach in $buffer2.

Ich glaube, er wollte eher die Implementierung auf der Serverseite
wissen...

Aber ich kann Karl Heinz nur beipflichten: mit den vorhandenen
spärlichen Informationen ist dem TE kaum zu helfen.  Ansonsten
schreibt man hier eine Abhandlung für einen Apache, während bei
ihm die Perlmodule Net::Server und HTML::Parser laufen (oder
so ähnlich, oder auch ganz, ganz was anderes).

[Björn R. (sushi)]

Ja, ich habe halt auch keine Glaskugel ;-)
Falls er das meint, was ich geraten hab, was er meinen könnte, hat er 
jetzt was. Habe ich aber auch nur gepostet weil ich selber gerade an dem 
Thema dran bin.
Ansonsten gebe ich euch natürlich völlig Recht, wenn er Hilfe will, soll 
er mal sagen was er eigentlich braucht und nicht sowas unverständliches 
unvollständiges dahinschreiben.

LG, Björn

[Karl H. (kbuchegg)]

Björn R. schrieb:
> Ja, ich habe halt auch keine Glaskugel ;-)

Willkommen im Club :-)

Ich hab noch eine 3. Variante
Der Web Server läuft auf einem PC und der AVR hängt irgendwie mit am PC 
(zb serielle). Der Apache auf dem PC soll auf einen GET hin den AVR über 
die Serielle befragen, der AVR antwortet und im Apache wird der Wert in 
die HTML Seite eingebaut.

Ist aber genauso geraten wie alles andere.

Ich favorisiere immer noch die Annahme, dass er ein AVR Board mit 
Ethernet Anschluss hat, auf dem ein Web Server läuft. Und diesem Server 
möchte er beibringen auf einen Get hin mit einem Wert aus dem EEPROM zu 
antworten.

Aber nichts genaues weiß man nicht.

Ich bin mir noch nicht einmal sicher, ob sich die Frage auf die 
Serverseite oder auf die Clientseite bezieht :-)

[Karl H. (kbuchegg)]

Entweder hat Björn ins Schwarze getroffen oder das Problem ist wieder 
mal von der Sorte 'so wichtig dann auch wieder nicht, als das man es 
nicht ignorieren könnte' :-)

[Hans M. (hans_maulwurf)]

1.) ich benütze eine selbst gebaute Variante des AVR NET IO
2.)darauf läuft der Stack von Ulrich Radig
3.)der User greift mit seinem Browser auf das Net io zu und wählt auf 
der Homepage den gewünschten Wert aus(funktioniert bereits bestens)
4.)der http server soll nun aus dem Get Request den spezifischen Wert 
erhalten und Werte aus dem EEPROM lesen und diese dann mit einer HTTP 
Response zurück senden.

Anbei ist das modifizierte Source File

[Karl H. (kbuchegg)]

Hans Maulwurf schrieb:
> 3.)der User greift mit seinem Browser auf das Net io zu und wählt auf
> der Homepage den gewünschten Wert aus(funktioniert bereits bestens)
> 4.)der http server soll nun aus dem Get Request den spezifischen Wert
> erhalten und Werte aus dem EEPROM lesen und diese dann mit einer HTTP
> Response zurück senden.

Tja. Das wirds so nicht spielen.
Soweit ich den Server überflogen habe, liefert der immer eine Web-Page 
zurück. Du kannst daher nicht mittels GET einen Wert anfordern.

Aber du kannst dem Web-Seiten Designer eine Möglichkeit zur Verfügung 
stellen, wie er Werte aus dem EEPROM in die zu liefernde HTML Seite 
einbauen kann.

Einen ähnlichen Mechanismus gibt es in diesem Server ja bereits

    //Müssen Variablen ins Packet eingesetzt werden? ===> %VA@00 bis %VA@09
    if (b == '%')
    {
      if (strncasecmp_P("VA@",http_entry[index].new_page_pointer,3)==0)
      {  
        b = (pgm_read_byte(http_entry[index].new_page_pointer+3)-48)*10;
        b +=(pgm_read_byte(http_entry[index].new_page_pointer+4)-48);  
        itoa (var_array[ b ],var_conversion_buffer,10);
        str_len = strnlen(var_conversion_buffer,CONVERSION_BUFFER_LEN);
        memmove(&eth_buffer[TCP_DATA_START+a],var_conversion_buffer,str_len);
        a = a + (str_len-1);
        http_entry[index].new_page_pointer=http_entry[index].new_page_pointer+5;
      }

Das ist Code, mit dem man offenbar in die HTML Seite so etwas wie 
Variablen einbauen kann, die in diesem Fall offenbar aus dem Flash 
kommen.

Auch für die Port Pins gibt es ja gleich darunter auch einen extra 
Abschnitt, mit dem man den Zustand in eine HTML Seite einbauen kann.

So etwas ähnliches kannst du dir auch für das EEPROM bauen.


Siehst du, wie schnell man da einen vernünftigen Vorschlag machen kann, 
wenn du nur genügend Informationen lieferst.

[Hans M. (hans_maulwurf)]

sicher muss das gehen ich werte die url aus,lese werte aus und sende 
diese dann mit der einen seite zurueck

[Karl H. (kbuchegg)]

Hans Maulwurf schrieb:
> sicher muss das gehen ich werte die url aus,lese werte aus und sende
> diese dann mit der einen seite zurueck

OK. Das deckt sich mit dem was ich vorgeschlagen habe.
Da hab ich dich wohl misverstanden. Ich dachte du willst bei einem GET 
den Wert direkt, nicht eingebettet in eine Seite.

Ist doch nicht weiter schwer zu realisieren. Für die Umkehrung kann man 
den gleichen Weg gehen, den Ulli mit dem PORT genommen hat und dann kann 
ein Client auch Werte im EEPROM hinterlassen.

Aber um eine Analyse der httpd_header_check wirst du nicht herumkommen. 
Auch sollte man sich überlegen, ob man diese Funktion nicht ein wenig in 
einzlene Funktionen auseinandernimmt. Die ist schon ein ziemliches 
Monster.

[Hans M. (hans_maulwurf)]

> Ist doch nicht weiter schwer zu realisieren. Für die Umkehrung kann man
> den gleichen Weg gehen, den Ulli mit dem PORT genommen hat und dann kann
> ein Client auch Werte im EEPROM hinterlassen.

Nur dass Ulli mit POST gearbeitet hat und nicht mit GET...ein kleiner 
Unterschied...

[Karl H. (kbuchegg)]

Hans Maulwurf schrieb:
>> Ist doch nicht weiter schwer zu realisieren. Für die Umkehrung kann man
>> den gleichen Weg gehen, den Ulli mit dem PORT genommen hat und dann kann
>> ein Client auch Werte im EEPROM hinterlassen.
>
> Nur dass Ulli mit POST gearbeitet hat und nicht mit GET...ein kleiner
> Unterschied...


Die Umkehrung!
Werte an den Server übertragen!

GET holt was vom Server
POST übermittelt etwas an den Server

In diesem httpd ist auch Code enthalten, mit dem ein Client am Server 
einzelne Pins am PORTA ein/ausschalten kann.

[Hans M. (hans_maulwurf)]

auf gut deutsch ich soll den vorhandenen code einfach anpassen?

[Karl H. (kbuchegg)]

Vergiss das mit der Umkehrung wieder.
Sieh zu, dass du deine EEPROM Werte in den vom Server erzeugten HTML 
Code einbaust.

[Hans M. (hans_maulwurf)]

Karl heinz Buchegger schrieb:
> Vergiss das mit der Umkehrung wieder.
> Sieh zu, dass du deine EEPROM Werte in den vom Server erzeugten HTML
> Code einbaust.

jawohl Sir.....

dass funktioniert schon

[STK500-Besitzer (Gast)]

>GET holt was vom Server
>POST übermittelt etwas an den Server

Würde ich nicht soo verallgemeinern.
Per GET kann man auch eine gewisse Menge Daten an den Server übertragen; 
halt nicht so viel wie per POST.
Passwörter sollte man auch nicht per GET übertragen...

[Hans M. (hans_maulwurf)]

> Passwörter sollte man auch nicht per GET übertragen...

das wäre auch ziemlich amateurhaft^^

[Simon K. (simon)]

STK500-Besitzer schrieb:
>>GET holt was vom Server
>>POST übermittelt etwas an den Server
>
> Würde ich nicht soo verallgemeinern.
> Per GET kann man auch eine gewisse Menge Daten an den Server übertragen;
> halt nicht so viel wie per POST.
> Passwörter sollte man auch nicht per GET übertragen...

Wobei POST da keinen Vorteil bietet erst mal. Das Passwort würde genau 
so Klartext übertragen.

Wollte aber auch erst das Gleiche schreiben wie du, aber Karl Heinz hat 
schon recht: Wenn man im echten Leben was zum Server senden will, nimmt 
man POST (Siehe Youtube Video uploading). Der Rest ist GET.

Ist ja auch suggeriert durch die Wörter GET und POST.

[Karl H. (kbuchegg)]

Simon K. schrieb:

> Wollte aber auch erst das Gleiche schreiben wie du, aber Karl Heinz hat
> schon recht: Wenn man im echten Leben was zum Server senden will, nimmt
> man POST (Siehe Youtube Video uploading). Der Rest ist GET.

Im Zweifelsfall versuche ich nach den Regeln zu spielen.
GET und POST haben ja einen bestimmten angedachten Zweck.

Klar kann man einiges auch misbrauchen und zu etwas zweckentfremden was 
der ursprünglichen Idee hinter der ganzen Sache etwas zuwieder läuft. 
Aber auf lange Sicht bin ich mit solchen Shortcuts einfach schon zu oft 
auf die Schnauze gefallen. Irgendwann rächen sich solche 'scheinbaren 
Vereinfachungen' meistens. Und wenn sie sich rächen, dann normalerweise 
heftig :-)