You are not logged in.
Pages: 1
Hi ab,
It is very handy to call Method based services and have TSQLRecordClass and record id in the TSQLRestServerCallBackParams context.
Is it possible to implement something like "ModelRoot/TableName/MethodName" ?
This will complement the use cases where method should be called against the whole table, without the need to specify it in additional url parameters.
Offline
AFAIK default RESTful implementation in the new TSQLRestServerURIContext class expects an URI encoded with 'ModelRoot/MethodName' or 'ModelRoot/TableName[/ID]/MethodName' formats.
Then you can use Table/TableIndex/TableRecordProps/TableEngine properties for direct access to the specified /TableName
Online
right, it works with latest sources (after BREAKING CHANGE)
thanks.
Offline
ab, after updating the source with the new TSQLRestServerURIContext I got following:
20131029 16374619 " EXCOS EAccessViolation (C0000005) at 001CF809 mORMot.TSQLRestRoutingREST.URIDecodeSOAByInterface (24348) stack trace API 001865C4 SynCommons.SynRtlUnwind (31512) 0000945C System.@HandleOnException
i := Server.Services.fListInterfaceMethod.IndexOf(URI); -> here Server.Services are nil
This happen every time when trying to call invalid (non-existing) method name of the rest server (and no interface services defined).
Maybe some handled error will be more suitable than showing AV exception with debug information to the client.
Also I was unable to get compression working.
Defined in the project COMPRESSDEFLATE, also tried to manually RegisterCompress, but with no luck.
Browser request compression, but the server never compress (tried also with big json as response).
Last edited by chapa (2013-10-29 14:54:46)
Offline
I've fixed the unexpected GPF.
It was indeed a regression due to the new class-driven implementation.
See http://synopse.info/fossil/info/0171854e68
and http://synopse.info/fossil/info/8acac4fc09
Thanks for the report.
For the compression, which browser are you using?
Online
thank.
using latest firefox and chrome.
right headers sent, but response is not compressed.
Offline
I believe it is some protocol handler on my win box.
Tried to disable the antivirus, but no luck, same problem.
Some protocol handler seem to decompress on the fly the http compressed response content and serve it uncompressed skipping Content-Encoding: deflate header from the http response.
If someone know how I can list/trace all protocol handlers in order to catch who is doing this will help a lot.
Thanks.
Offline
I just checked with the sample program HttpApiServer - and found no problem with Chrome: the content is encoded with "deflate".
Which server class are you using?
The Socket-based or the HTTP.SYS-based?
What is the content type of the returned data?
We only compress 1KB of TEXT/ or APPLICATION/XML or APPLICATION/JSON kind of data.
Please ensure your server does execute the function CompressDataAndGetHeaders().
Use the debugger to see what's wrong.
Online
I confirm - there is no problem with compression. I use gzip. Last version of Chrome and Firefox - all content > 1Kb gzipped successfully. If you not sure your browser plugins do uncompression or not - use http://fiddler2.com/ as a proxy and see there.
Last edited by mpv (2013-10-30 16:46:50)
Offline
1. HTTP.SYS one.
2. application/json
3. debugged and ensured it returns compressed content and size
Chrome, Firefox even command line wget.exe returns uncompressed data (wget with Accept-Encode headers set). Tried connecting from localhost to: 1.localhost (for debugging) and 2. remote server (production).
But ... when accessing my computer and production server from other machines, data is compressed ...
This leads my mind, that some antivirus or other http protocol handler on localhost catches the response and manipulate it.
Offline
Hm.. If in fiddler you also don't see compression headers try http://www.wireshark.org/ - I use sometimes this tool to analyze network on low level.
Offline
Forgot to mention, fiddler also tried, no Content-Encoding header in the response, body is decompressed.
Fiddler is a proxy, they use .NET classes to access Inet, AFAIK.
Once I used to write protocol handlers. Before response hit the client it can be manipulated by several handlers. So I guess it is something like that sitting between the client and actual response.
For protocol handler point of view it does not mind who the client is.
Will give a try to wireshark tomorrow and let you know.
Last edited by chapa (2013-10-30 17:06:59)
Offline
debugged and ensured it returns compressed content and size
Chrome, Firefox even command line wget.exe returns uncompressed data (wget with Accept-Encode headers set). Tried connecting from localhost to: 1.localhost (for debugging) and 2. remote server (production).
But ... when accessing my computer and production server from other machines, data is compressed ...This leads my mind, that some antivirus or other http protocol handler on localhost catches the response and manipulate it.
So... data is compressed!
Online
Pages: 1