[PHP] serialize maar dan kleiner

[hobbit_be]

Hoi

naar aanleiding van een previous topic heb ik mijn php "engine" omgezet om gebruikt te maken van encoded parameters. ie:

ik heb altijd maar 1 GET/POST var: die "o" noemt.

deze "bevat" een serialised/base_64/urlencoded object (altijd een array in mijn geval).

Leuk en werkt prima. Maar nu vind ik de strings wel ERG groot worden voor kleine zaken. bijvoorbeeld:

array [array[100,200,300],array[20]]; is erg groot (zal rond de 100 chars liggen).

dat base64 daar 1/3 bij doet kan ik niet om en is ook niet te erg, wel erger is het feit dat de serialize gewoon een string genereert die erg verboos is.

Vraag ik me af zijn er geen binary serialize/unserialize functies of utils te vinden - ik heb me al blauwgezocht.

Om alles eerst te gaan GZippen vind ik wel beetje extreem gaan maar sltui ik niet uit (maar dat is weer "niet standaard" php en weer extra tijd).

Ofcourse komt daar dan nog eens security encryption over .

Maar mijn google werk vind niets relevants terug. Snap het niet want eigenlijk is dat toch wel erg handig voor php zelf (die die dingen toch ook gebruitk voor zijn sessions?)

[ACM]

De serialization is geloof ik vooral bedoeld om een tekststring te krijgen van iets, dus dan kan je maar beter niet proberen een binary-string te encoden.

Sowieso is php niet zo sterk in binary zaken (binary writes kunnen geloof ik niet eens?).
Voor de sessions wordt geloof ik idd geen gewone serialize geschreven, maar ook die lijkt me niet extreem efficient?
Als je weet dat het altijd een array met getallen is, dan zou ik zelf een encoder maken ervoor, die iets als [1,2,3,[4,5,6],7,8] retourneert, dat is met een simpele recursieve functie wel te maken en uit te lezen

[hobbit_be]

helaas was dat getal voorbeeld maar een voorbeeld en kan er dus vanalles in zitten. (nou ja zal wel blijven bij strings en getallen)

ik vrees dat ze te lang gaan worden voor een "GET".

als ik tijd heb zal ik dus zelf maar een serialize moeten schrijven of alleen nog maar met "post" werken.

begin me af te vragen of mijn "OO" approach wel gaat werken met al dat gedoe. Maar niets
handiger dan:

PHP:

$TemplateVar = $this->dispatch("group.list",array(12));

en dat deze dan volledig transparent aankomt als

PHP:

class Group
{
   function onList($whatgroup)
   {
      ...
   }

}

toch?

[ACM]

Lol, zo'n soort template-systeem heb ik ook lopen uitwerken voor een projectje

Maar ik doe wat minder met lange urls (hoewel ze waarschijnlijk ook wel richting de 200a500 karakters gaan).
Als je zeker weet dat je urls langer dan 1000 karakters krijgt, dan kan je idd beter op het gebruik van POST richten, of eventueel "standaard zaken" in sessies en dergelijke gaan verwerken en zo veel mogelijk de sessie bijwerken ipv in de GET-requests gaan stoppen.

[djc]

Eventueel ook de PATH-INFO gebruiken in plaats van een GET parameter, zoals React dat bijvoorbeeld ook doet.

[hobbit_be]

Tja het werkt wel erg gemakkelijk moet ik zeggen (ook pretty impossible to abuse).

Session gebruik ik natuurlijk al hier en daar (waar het moet) ,en per "object". Nu nog mijn java DataObjects omzetten en het is af . Probleem om zulke dingen in sessions te gaan steken is wat als de user "Back" gaat -> dan krijg ik denk ik toch wel een paar "foute" states.

tja die PATH-INFO, dat vind ik ook wel geinig maar kan ik dat "puur" in PHP of moet daar de server "meewerken"?. het zou idd leuk zijn mysite/group/list/$/1/12 maar dan moet je die directory structuur toch ook opzetten? Zal morgen eens onderzoeken...

Note: ik had het "gezipped" en nu is het nog langer .

Altijd leer je iets bij op dit forum...

[drm]

hobbit_be:
tja die PATH-INFO, dat vind ik ook wel geinig maar kan ik dat "puur" in PHP of moet daar de server "meewerken"?. het zou idd leuk zijn mysite/group/list/$/1/12 maar dan moet je die directory structuur toch ook opzetten? Zal morgen eens onderzoeken...

P&W FAQ - PHP (in case of Apache)

Maar of dat wat uitmaakt voor de maximale lengte van de url geloof ik niet. Volgens mij mag uberhaupt de request uri header maar maximaal 1024 characters _{(zuig ik uit m'n duim, kan best een ander getal zijn)} zijn, en schiet je dus enkel de namen van de variabelen ermee op. Als je zelf een goede/efficiente (de)serializer schrijft heb je die namen toch al niet nodig, en zou je het dan alleen maar doen omdat het er netter uit ziet

Verder zou ik ervoor opten zoveel mogelijk in een sessie te stoppen en de zaken die uit de sessie overschreven moeten worden via get (of post) te accepteren. Om een hele site op basis van posts te doen lijkt mij niet nodig. 't Is ook niet erg efficient, want uiteindelijk kost 't ook een hoop overhead in het verkeer.

[ACM]

De limiet voor IE is iets van 2038 karakters, mozilla-varianten hebben 4096 oid en officieel is er geen limiet. Maar een limiet van ~1024 aanhouden voor de grens waarop je POSTs gaat overwegen ipv GETs is niet onverstandig denk ik.

Zeker als je altijd boven de 1024 eindigt ipv af en toe.

[drm]

idd Daar komt bij (lees ik net) dat de server er ook restricties op mag leggen. Ik neem aan dat dat zo weinig mogelijk gedaan wordt, maar 't is iig dus iets om bij stil te staan.

quote: http://www.faqs.org/rfcs/rfc2616.html

(3.2.1 General Syntax)
[..]
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.

quote: http://www.faqs.org/rfcs/rfc2616.html

(10.4.15 414 Request-URI Too Long)

The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. This rare
condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query
information, when the client has descended into a URI "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to
exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the Request-URI.

Wat ACM zegt, dus, theoretisch zijn er dus geen limieten, maar in de praktijk is het iets om rekening mee te houden, zowel voor de server als voor de client.

[Suepahfly]

Misschien is dit wat voor je
http://www.tonymarston.net/php-mysql/encryption.html

Bron:
http://www.tonymarston.ne...=std.encryption.class.inc

Met deze class kan je dus een string encrypten/decrypten. Ik heb ben van plan deze te gebruiken voor bepaalde data die ik niet plain text wil opslaan.

de lengte van je encrypted string wordt deels bepaald door een een interger die aan de functie mee geeft.

Je kan een online test formulier vinden op http://www.tonymarston.net/php-mysql/encryption.php


`dit is een string`
wordt
`cBdQx`
met als password `blaat` en een password Length van 6, de rest standaard waarden

[hobbit_be]

ok die Path-Info is dus "in samenwerking met". Helaas weet ik op dit moment niet dat het systeem op IIS of Apache of XServe gaat draaien dus dat laat ik voorlopig achterwege.

Leuke aan zo'n RPC is dat ik alleen maar de encoding moet veranderen (en hoe worden de href/action/js erin geplakt) dat ik wel op zoiets kan overstappen mocht het handiger zijn.

Heb al ontdenkt dat ie met zlib eigenlijk steeds minder begint te groeien (geen wonder) dus 1024 (of 512 om maar zeker te zijn) geraakt ie wel aan maar de function calls zijn nooit zo groot. ie: echt input variable (ie TextArea enzo) worden gewoon met post gedaan. Hmm nu ik dit zit te typen kan ik die ook ineens als parameter doorgeven (maar dan server side decoded). Hmmm verdomme weer iets handigs om toe te voegen

Tja werken met sessions - blijft de vraag ivm "state" van de machine. Vroeger stopte ik ook alles in een session maar door op "back" te doen ging er dan meestal wel iets mis. Ik gebruik ze al voor alles what IMHO erin moet staan (het mechanisme is uiteindelijk niets anders dan "methods" aanroepen op het "object" dat al zijn "member" data in een session heeft staan.) Hier en daar geef ik vast iets te veel mee, maar zoals een eerdere post elk "object" (meestal ineens een andere php file) krijgt zijn eigen (faked) "session" var om dus voor elk "object" zijn state bij te houden. (eg: als je group.list(14) doet gaat ie de volgende keer (eg: group.users.remove(11,12,13) wel weten dat ie dat voor groep 14 moet doen))

om toch met die "dispatch" te werken had ik al gedacht om in de session een loop-up-table te maken met daarin de corresponding calls: ie: groups.list word dat doodweg 0 maar wederom dan moet de session daar op "voorbereid" zijn. Het is in feite dan een soort van transactie systeem waar je alle mogelijke transacties eerst moet voorbereiden.

ie:

step1: geef naam in (=user.name.submit() = 1) [1 staat dus al in de sessie]\
step2: (on post) LUT [1] = user.name.submit() (dispatch),
geef leeftijd (=user.age.submit() = 1) [overwrite, want anders kan ik steeds meer ids aanmaken)..

en door de overwrite kan het dus zijn dat ie dan door een back / refresh iets "anders" gaat doen. Tenzij ik het "word" encode (ie user=1, name=2,...) natuurlijk .

En om van die get weg te geraken zou ik eventueel op elke pagina een empty form kunnen zetten die ik dan met js "submit" (iets dat ie nu al doe voor een gewoon form) maar moet je dan

code:

<a href="javascript:gSubmit('askIJNM1ASDhjhsdsdsd'" /> of
<a onClick="..."/> of zelfs helemaal geen "a" meer.

> die encryptie classe is ideaal voor een snelle encryptie op de tag. Ik ga ook nog in de sessie een "counter" insteken zodat je niets kan submitten als de nieuwe "ouder" is. wou alles eerst gaan PGP-en maar das een CGI call (net iets te zwaar als je 20/30 encoded hrefs per pagina hebt . Thx Suepahfly.

Vinden jullie het optimimaliseren ook leuker dan uiteindelijk iets met het systeem doen .

offtopic:
bemerk net het onoemelijk veel gebruik van ""

[ Voor 7% gewijzigd door hobbit_be op 09-12-2003 10:10 ]