3. Sessions

Sessions

  • R

    Ein Beispielrequest sieht folgendermaßen aus:

    GET /index.htm HTTP/1.1*
    Host: BlaBla*
    *

    Wobei immer bei * ein CLRF hin muss. Es fehlt also nicht nur am Ende ein CLRF (wobei am Ende 2 ClRFs hinmüssen)

    0
  • R

    muss ich dann CLRF quasi im klatext schreiben, oedr \r\n da hinpacken?

    0
  • R

    ray_ray schrieb:

    bin auch soweit, dass ich eine verbindung zum server über sessions gemacht hab.

    Wie kannst du eine Verbindung über Sessions zu einem Server herstellen? Du meinst Sockets?
    Sessions sind eine Möglichkeit Daten (z.B. in PHP) über Requestgrenzen hinweg userabhängig zu speichern.

    0
  • R

    ray_ray schrieb:

    muss ich dann CLRF quasi im klatext schreiben, oedr \r\n da hinpacken?

    \r\n

    0
  • M

    \r\n

    0
  • R

    habe die zeile jetzt so:

    string strRequestMessage = "GET " + this->m_strFolder + " HTTP/1.1 CLRF Host: " + this->m_strServer + " CLRF CLRF";

    ändern tut sich aber imer noch nix. der wartet noch imer ewig auf antwort.

    0
  • R
     

    string strRequestMessage = "GET " + this->m_strFolder + " HTTP/1.1\r\n Host: " + this->m_strServer + "\r\n\r\n";
    0
  • R

    sry
    werds jetzt mit \r\n probieren

    und du hast recht, ich meine sockets. weiß nich wo ich mit meinem kopf war 😉

    0
  • V

    http://www.faqs.org/rfcs/rfc2068.html

    0
  • V

    Hol dir Packteyzer (kostenlos) und schau dir an weleche daten du wirklich sendest

    0
  • R

    Ein weiteres Problem, das du hast, ist, dass du recv die anzahl der Bytes übergeben musst, die es lesen soll. Wenn du zu wenig angibst, wird nicht der ganze Response empfangen, wenn du zu viel angibst, verzögert sich recv.
    Ich hab etwas ähnliches mal im Zuge eines Referates gemacht.
    Meine Lösung war, dass ich den Response Header nach dem Content-Length parse, das ja die Anzahl der Bytes im Body angibt.
    Hier ein Auszug:

    // receive response
ULONG nBytesTraffic = Cache.nRequestLength;
int nBytesReceived = 0;
BOOL bResponseIsHeader = TRUE;
char cTmpBuffer = 0;
// receive header
UINT nContentLength=0;
char strLastHeaderLine[150];
char cLastChar = 0;
memset(strLastHeaderLine, 0, 150);

while (true)
{
    recv(mySocket, &cTmpBuffer, 1, 0);
    nBytesTraffic ++;
    if (cTmpBuffer != '\n')
    {
        strLastHeaderLine[strlen(strLastHeaderLine)] = cTmpBuffer; // bufferoverrun hier möglich
    }
    else
    {
        UINT nPossibleLength = 0;
        if (sscanf(strLastHeaderLine, "Content-Length: %d", &nPossibleLength)>0)
        {
            nContentLength = nPossibleLength;
        }
        memset(strLastHeaderLine, 0, 150);
    }
    if (cTmpBuffer == '\r' && cLastChar=='\n') // nach \r\n endet der Header
    {
        break;
    }
    cLastChar = cTmpBuffer;
}

for (int nBytesLeft=nContentLength; nBytesLeft>0; nBytesLeft--)
{
    recv(mySocket, &cTmpBuffer, 1, 0);
    nBytesTraffic ++;
}
    0
  • V

    Rapha schrieb:

    Meine Lösung war, dass ich den Response Header nach dem Content-Length parse,

    manchmal wird die Content-Length nicht übermittelt

    0
  • R

    in dem rfc stehen diese 2 möglichkeiten

    GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

    GET /pub/WWW/TheProject.html HTTP/1.1
    Host: www.w3.org

    zumindest find ich nur die 2

    0
  • R

    Vertexwahn schrieb:

    manchmal wird die Content-Length nicht übermittelt

    Das hab ich noch nie gesehen 😉

    Andere Lösungs-Theorie:
    Das Problem ist, dass der HTTP-Webserver die Verbindung nach dem Request nicht beendet. Du könntest versuchen ein HTTP 1.0 Request zu senden (anstatt 1.1), da der Server afaik die Verbindung nach einem Request schließt

    EDIT:
    Wenn du unter Windows arbeitest, würde ich den Request nicht von Hand schreiben, sondern WinInet verwenden.

    0
  • R

    so, habe da jetzt noch ein bissl nach eurer anleitung verändert. das problem war tatsächlich der letzte parameter bei recv. hab den jetzt einfach ma genauso groß gemacht wie die variable für die antwort. die sache is jetzt die. der empfängt jetzt was (dank euch) und hält sich halt nich ewig mit dem warten auf. jedoch gibt er nix aus. die entsprechenden zeilen sind die:

    //	Request zusammenstellen und abschicken
string strRequestMessage = "GET " + this->m_strFolder + " HTTP/1.1 \r\n Host: " + this->m_strServer + " \r\n \r\n";

//	Request erfolgreich ausgeführt
if( send( (SOCKET) this->m_Socket, strRequestMessage.c_str(), strlen( strRequestMessage.c_str() ), 0 ) )
{
	//	Statusmeldung ausgeben
	cout << endl << "  HTTP Request:" << endl << "  >> Uebertragung erfolgreich" << endl << endl << "  ";

	//	-------------------------------
	//	Response auswerten und ausgeben
	//	-------------------------------
	int nReciveStatus = recv( ( SOCKET ) this->m_Socket, this->m_szRespose, 1000, 1000 );				

	if( nReciveStatus > 0 )
	{
		cout << endl << "  HTTP Response:" << endl << "  >> " << this->m_szRespose;
		this->m_szRespose[ nReciveStatus ] = 0;
		cout << endl << "  >> " << this->m_szRespose;
	}
}
    0
  • R

    Rapha schrieb:

    Ein weiteres Problem, das du hast, ist, dass du recv die anzahl der Bytes übergeben musst, die es lesen soll. Wenn du zu wenig angibst, wird nicht der ganze Response empfangen, wenn du zu viel angibst, verzögert sich recv.

    Genau das hab ich ja bereits angesprochen (siehe mein vorheriger Post) 😉

    0
  • R

    wenn ich mir die nReciveStatus ansehen ist diese auf -1 nach dem recv(). das heißt doch, dass das ganze ien fehrlschlag ist, oder? dann wäre es nämlich kein wunder dass der nix ausgibt. bei -1 geht der ja auch nicht ins if rein, was danach kommt.

    0
  • R

    Übergib recv mal nicht 1000 sondern z.B. 5

    0
  • R

    da ändert sich dann auch nichts, wenn ich 5 oder 9 oer 17 oder so mache. aber mit dem request hat der fehler jetzt nichts zu tun, oder? nich das der request falsch ist.

    0
  • R

    gib dir doch mal den Request mit cout aus und teste ihn mit telnet (poste ihn am besten noch hier rein).

    0
Anmelden zum Antworten