[haXe] Client-server remoting using headers

[Franco Ponticelli]

Fixed by browsers development teams ... that is good ;-)

On Dec 8, 2007 11:16 AM, Benjamin Dasnois <benjamin.dasnois at gmail.com>
wrote:

> Hello Michael,
>
> that's quite interesting... On which browsers did you have this behavior?
>
> I think that implementing this workaround is a good but this should be
> fixed by browsers not by us IMHO...
> So let's get this back to the concerned browser's development teams
> (if possible...)
>
> Regards,
>
> Benjamin
>
>
>
> On Dec 7, 2007 10:37 PM, Michael Pliskin <mike at comapping.com> wrote:
> > Hello list,
> >
> >   I've found a pretty strange problem with haxe remoting recently, and
> >   I'd like to discuss a workaround. In our app, I need to send smth
> >   like 'logout' message when user closes browser/navigates away from
> >   the page. I am setting up an onunload handler in JS to send the
> >   message at the right time. The problem is (as my recent findings
> >   show) that for some weird reason in some cases only headers from
> >   this request reach server, not the request body itself. This leads
> >   to haxe remoting not working - while headers arriving successfully!
> >
> >   So the workaround I propose is to introduce a 'header mode' into
> >   haxe remoting - when data is sent not via __x parameter in request
> >   body, but via some header (say X-Haxe-Remoting-Data). Of course this
> >   will only work for short messages I think - but this is more than
> >   enough for me.
> >
> >   Nicolas & all, thoughts? If you like, I can make a patch..
> >
> > --
> > Best regards,
> >  Michael                          mailto:mike at comapping.com
> >
> >
> > --
> > haXe - an open source web programming language
> > http://haxe.org
> >
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20071208/d84ef707/attachment.htm