Debugging vaadin UIDL post data


so, looking at the vaadin book i see these two wonderful pages:

giving an in-depth explanation of uidl and even how to debug it using firebug.

But, what i am looking for is understanding the POST data sent by vaadin, which is not covered and the format is unclear to me. whipping up trusty wireshark, i come up with this (for example):


so, this doesn’t look like JSON or anything else. I’d guess 4b4b1b0b-daa8-4053-beb5-d405d841da54 is some kind of client identification, the ‘true’ there some value (of what though??), PID78 means paintable #78 and state b is seems fair. so far basically good. but what about this??


what is the parse rule? what is that ‘8’ doing after the uuid / how does it relate to that ‘true’ above? why are some separators \035, some \036 and some \037? is there any consistent way to make sense out of this?



Variable changes we are posting from browser to the server is not JSON. You shouldn’t need to care about it, but just use updateVariable methods in the ApplicationConnection class. The state information we post form server to the browsers is JSON.

If you want to see what is been sent from the browser to the server you could use the client side debug dialog opened by appending query parameter “?debug=true”. Or more intuitively for a java developer, put a break point on the server side counter parts changeVariables() method.



thanks, but my intents kind of require that I understand what the post format means. I want to be able to reconstruct a problem when provided with a recording of the http traffic (a .har file).

are you sure that format is not documented anywhere?

The format is not explicitly documented and is considered an implementation detail in current versions - the APIs for sending variable changes from the client to the server and how the variable changes are seen on the server are better documented (on the client side is ApplicationConnection.updateVariable(…) and on the server side VariableOwner.changeVariables()).

In any case, the format of the messages from the client to the server currently consists of one or more burst of variable changes (preceded by a security key). You can see a better formatted version of what will be sent in the debug window with the URL parameter “?debug”. File uploads are sent separately, not in these variable bursts.

The places to look at to parse the format are ApplicationConnection.makeUidlRequest() and ApplicationConnection.buildAndSendVariableBurst() on the client side and AbstractCommunicationManager.doHandleUidlRequest() and AbstractCommunicationManager.handleVariables() on the server side. Only simple datatypes (some primitive types, Strings, Paintable (Component) references and Maps) are supported, and component references are sent as PIDs (generated paintable IDs or debug IDs if set).