logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak zakończyć przesyłanie danych HTTP w mini serwerze na ATmega162?

dan_mad 12 Lut 2007 13:00 2219 7
REKLAMA
  • #1 3559479
    dan_mad
    Poziom 10  
    Posty: 50
    Pomógł: 1
    Witam

    Jako że po przejrzeniu wszystkich postów dotyczących tematu mini serwera na mikrokontrolerze nie znalazłem w miarę podobnego "problemu" pozwoliłem rozpocząć nowy temat który jest jednocześnie pytaniem.
    Wykonałem taki układ który składa się z właściwego procka typu ATmega162 podłączonego do sieci typu LAN poprzez konwerter Serial/LAN typu AR-727CM. Program w mikrokontrolerze czeka na żądanie wysyłania danych od przeglądarki i odpowiada wysyłając najpierw w protokóle HTTP "HTTP/1.0 200 OK<CR><LF>" i następnie właściwe dane w html'u. Stronka ładnie się wyświetla w oknie przeglądarki i... nie wie że to już koniec danych które ma wyświetlić.
    Moje pytanie w związku z tym jest takie, czy ktoś już "rozgryzł" wrzucanie protokołu HTTP do mikrokontrolera na tyle że wie o co tu może chodzić (niestety wszystkie próby przesłania innych poleceń protokołu HTTP np. "Content-Type: text/html<CR><LF>" i innych z którymi próbowałem ustawiać parametry odpowiedzi do przeglądarki nie udały się i przeglądarka traktowała je jak zwykły tekst). Druga sprawa to taka czy to może mieć coś wspólnego z tym że robię to za pośrednictwem konwertera , co oznacza że nie mogę np. wprost zamknąć socket'a.
    Mam nadzieję że wyraziłem się w miarę jasno i czekam na kogoś kto mógłby Mi rzucić nieco światła w tym temacie, czekam również na ewentualne pytania do Mnie w tym temacie.

    Pzdr. DM
  • REKLAMA
  • #2 3559764
    thenkles
    Poziom 11  
    Posty: 76
    Ocena: 1
    Może spróbuj dodać nagłówek:

    Connection: Close
  • REKLAMA
  • #3 3560700
    starob
    Poziom 29  
    Posty: 1088
    Pomógł: 128
    Ocena: 137
    Też miałem z tym kłopoty, ja wysyłam:

    HTTP/1.0 200 OK<CR><LF>
    Server: uC8051<CR><LF>
    Content-type: text/html<CR><LF>
    <CR><LF>
    <html>
    itd...
    sam nie wiem dlaczego tak ale działa i tylko tak
  • #4 3564879
    dan_mad
    Poziom 10  
    Posty: 50
    Pomógł: 1
    Jakoś udało Mi się wymęczyć rozwiązanie. Daję taki nagłówek:
    HTTP/1.0 200 OK<CR><LF>
    Server: ATmega162<CR><LF>
    Keep-Alive: timeout=15, max=100<CR><LF>
    Connection: Keep-Alive<CR><LF>
    Content-Length: 350<CR><LF>
    Content-Type: text/html<CR><LF>
    <CR><LF>
    i następnie właściwą stronę:<html>...</html>.
    Jedyna niedogodność tego rozwiązania jest taka że należałoby wiedzieć ile bajtów mamy przesłać jako parametr w wierszu "Content-Lenght:", aby uniknąć kalkulowania przy okazji każdej zmiany, na razie robię taki "chamski" numer i podaję tą wartość z zapasem a po przesłaniu właściwych danych w HTML'u dopełniam brakujące bajty kilkudziesięcioma znakami <CR><LF>. Jak bajtów danych do przesłania jest mniej niż się podało to w oknie przeglądarki pojawia się od nowa zawartość HTML'owa ale "poszatkowana". W tej chwili ważne jest że działa ten sposób bez problemu.
  • REKLAMA
  • #5 3565053
    William Bonawentura
    Poziom 34  
    Posty: 2426
    Pomógł: 191
    Ocena: 622
    dan_mad napisał:
    Jakoś udało Mi się wymęczyć rozwiązanie. Daję taki nagłówek:
    HTTP/1.0 200 OK<CR><LF>
    Server: ATmega162<CR><LF>
    Keep-Alive: timeout=15, max=100<CR><LF>
    Connection: Keep-Alive<CR><LF>
    Content-Length: 350<CR><LF>
    Content-Type: text/html<CR><LF>
    <CR><LF>
    i następnie właściwą stronę:<html>...</html>.
    Jedyna niedogodność tego rozwiązania jest taka że należałoby wiedzieć ile bajtów mamy przesłać jako parametr w wierszu "Content-Lenght:", aby uniknąć kalkulowania przy okazji każdej zmiany, na razie robię taki "chamski" numer i podaję tą wartość z zapasem a po przesłaniu właściwych danych w HTML'u dopełniam brakujące bajty kilkudziesięcioma znakami <CR><LF>. Jak bajtów danych do przesłania jest mniej niż się podało to w oknie przeglądarki pojawia się od nowa zawartość HTML'owa ale "poszatkowana". W tej chwili ważne jest że działa ten sposób bez problemu.


    Bo sam sobie robisz problemy używając trybu KeepAlive (kila zapytań w jednej sesji TCP). Wtedy potrzebny jest Content-Length. Minimum jakie musisz wysłać to pierwszą linię (HTTP...) oraz nagłówek Content-Type. Dalej pusta linia i treść. Koniec pliku oświadczasz zamykając połączenie TCP. W serwerku który nie musi mieć super wydajności nie warto bawić się w KeppAlive
  • #6 3565429
    dan_mad
    Poziom 10  
    Posty: 50
    Pomógł: 1
    Cytat:
    Koniec pliku oświadczasz zamykając połączenie TCP.


    Używam konwertera Serial/LAN i nie mogę zamknąć połączenia wydając jakieś polecenie z mikrokontrolera. Zamknięcie portu w konwerterze następuje automatycznie po 60s. nieaktywności. Przy próbach z prawidłowym typem nagłówka nie działała Mi opcja Connection: Close, zaproponowana przez thenkles. A jeśli chodzi o tryb Keep-Alive to zauważyłem że jest to domyślna opcja wychodząca od strony przeglądarki i "trzyma" równo 300s. ( jeśli nie używam Content-Length ).
    Mimo to będę próbował załatwić to w jakiś bardziej elegancki sposób, chociaż przy gotowej stronce w html'u nie jest to jakieś super uciążliwe ( Content-Lenght ).
  • #7 3568317
    William Bonawentura
    Poziom 34  
    Posty: 2426
    Pomógł: 191
    Ocena: 622
    dan_mad napisał:
    Używam konwertera Serial/LAN i nie mogę zamknąć połączenia wydając jakieś polecenie z mikrokontrolera.

    A jeśli chodzi o tryb Keep-Alive to zauważyłem że jest to domyślna opcja wychodząca od strony przeglądarki i "trzyma" równo 300s. ( jeśli nie używam Content-Length ).


    No to faktycznie masz problem z tym konwerterem. A przeglądarka wysyła nagłówek informując, że potrafi i CHCIAŁABY utrzymywać to połączenie w keep alive. Serwer odpowiada że potrafi to robić (wtedy musi też wysłąć content-length) albo to ignoruje.
  • REKLAMA
  • #8 3568932
    dan_mad
    Poziom 10  
    Posty: 50
    Pomógł: 1
    Cytat:
    A przeglądarka wysyła nagłówek informując, że potrafi i CHCIAŁABY utrzymywać to połączenie w keep alive. Serwer odpowiada że potrafi to robić (wtedy musi też wysłąć content-length) albo to ignoruje.


    Próbowałem jeszcze powalczyć z tym parametrem Content-Length pod kątem obsługi tego parametru w różnych przeglądarkach. Do tej pory próby przeprowadzałem w FireFox'ie. Po zapytaniu z InternetExplorera6 cały układ działa dokładnie tak jak opisuje to William Bonawentura i parametr w Content-Length nie ma znaczenia ( ale go nie ignoruje, za mały parametr powoduje "ucięcie" strony w FireFox'ie ) a port jest zwalniany po czasie określonym parametrem "Keep-Alive: timeout=15, max=100<CR><LF>" i generalnie działa Mi to dokładnie tak jak chciałem.
    Jeszcze jedna sprawa dotycząca różnic między przeglądarkami, to obsługa formularza. IE6 po naciśnięciu przycisku w formularzu wysyła zapytanie w protokóle HTTP gdzie jednym z parametrów jest to co wpiszemy w definicji formularza po słowie ACTION= , natomiast FireFox otwiera tylko połączenie i nie zadaje żadnego pytania.
    Po czymś takim zastanawiam się czy robić od razu to wszystko "pod" IE ?

Podsumowanie tematu

LABEL_AI_GENERATED
Dyskusja dotyczy problemu zakończenia przesyłania danych HTTP w mini serwerze opartym na mikrokontrolerze ATmega162 podłączonym do sieci LAN przez konwerter Serial/LAN AR-727CM. Wysyłanie odpowiedzi HTTP rozpoczyna się od linii statusu "HTTP/1.0 200 OK" i danych HTML, jednak przeglądarka nie rozpoznaje końca transmisji. Rozwiązania obejmują dodanie nagłówków takich jak "Content-Type: text/html" oraz "Connection: Close" lub "Keep-Alive" wraz z określeniem "Content-Length". Użycie trybu Keep-Alive wymaga podania dokładnej długości treści, co jest trudne do precyzyjnego obliczenia, dlatego stosowano nadmiarową wartość i dopełnianie brakujących bajtów znakami CR LF. Problemem jest brak możliwości zamknięcia połączenia TCP z poziomu mikrokontrolera ze względu na działanie konwertera, który zamyka połączenie po 60 sekundach bezczynności. Różnice w zachowaniu przeglądarek (Firefox i Internet Explorer 6) wpływają na obsługę nagłówków i formularzy HTTP. W praktyce najprostsze i niezawodne jest wysłanie nagłówków HTTP z "Content-Type" i zamknięcie połączenia przez konwerter, unikając trybu Keep-Alive, który wymaga precyzyjnego zarządzania długością danych.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA