Re: [Mono-dev] Review of PR1354 - add Request.Abort()

2014-10-19 Thread Martin Thwaites
Thanks Miguel,

From the documentation, it simply says it throws an exception if not
integrated so that should be simple to add.  I wasn't aware that the
pipelines existed in mono which is why I've not done it.  Is there an
example of doing a check that you know of off the top of your head?

In terms of usage, it's used in the WebAPI/MVC, and doesn't appear to be
malicious related so maybe it's being misused there.  I would imagine
though that it's around theory of keeping connections open to the server
(probably for something like websockets?).

Thanks,
Martin

On 19 October 2014 00:56, Miguel de Icaza mig...@xamarin.com wrote:

 Hey Martin,

 Thanks for the patch;   The documentation describes that this has two
 behaviors depending on the pipeline mode in use:


 http://msdn.microsoft.com/en-us/library/system.web.httprequest.abort(v=vs.110).aspx

 It might be good to find out if there are other things that this call
 should do beyond closing the connection.  It seems like it was intended to
 be used against a malicious HTTP client (which I have no information about
 what they mean by this).



 On Sat, Oct 18, 2014 at 5:40 PM, Martin Thwaites monofo...@my2cents.co.uk
  wrote:

 Hi all,

 I've just submitted a pull to add Request.Abort() to the HttpRequest
 class.  It simply calls CloseConnection on the worker request so it's
 pretty simple.

 I'm not sure how to add a unit test for this so any help would be
 appreciated.

 This is for the work I'm doing on getting the aspnetwebstack working.

 https://github.com/mono/mono/pull/1354

 Thanks
 Martin

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] State of aspnetwebstack on mono

2014-10-19 Thread Martin Thwaites
Hi all,

Just wanted to give a quick update on where I'm at with getting things
implemented for the aspnetwebstack to work on mono.

As I've said before, my goal is to make it so that the aspnetwebstack
solution will compile against mono, without tweaking anything (this is
stage 1).  It's proving to both a relatively small task, but also very
taxing in terms of me having to learn quite a lot.

*Note: I'm not looking at the tests in aspnetwebstack at the moment, that
will be stage 2, a lot seem to require things we don't have yet.*

In summary, it's not that far off, and once it's done, at least we'll be
able to see which methods may need bugfixing as the webstack will load at
least.  The main issue is getting the PRs approved, but my hope is that if
we can collate a list of the all, we can ask that they are reviewed
together and considering they will make one of the most up and coming web
technologies work on mono, I would say there is a good reason to try and
prioritise it.

Here are the current PR's, I've reviewed the ones that aren't mine and they
now look ok, we just need a contributor to review/merge them.

PR874 - from Chris Carroll with a few properties implemented around routes
PR1163 - from AerisG222 which includes a few changes around Unvalidated
parameters and some other bits
PR1349 - From me regarding MachineKey.Protect methods
PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work, just
the interface)
PR1354 - From me regarding Request.Abort

Outstanding items that I could do with help with:


   1. ReadEntityBodyMode needs properly implementing
   2. Request.GetBufferedInputStream needs implementing.
   Request.GetBufferlessInputStream needs implementing (looks like it's
   already partially implemented).
   3. HttpResponseBase.SuppressFormsAuthenticationRedirect needs
   implementing
   4. HttpTaskAsyncHandler needs implementing.
   5. HttpResponse.ClientDisconnectedToken needs implementing (can just
   return CancellationToken.None and it should be fine but a proper
   implementation would be better).
   6. Do something about System.Data.EntityState, it's supposed to live in
   System.Data.Entity.dll which we don't have but MVC checks against.
   7. Do something about System.Web.UI.DataVisualization.Charting, I don't
   want to have to change the aspnetwebstack code to exclude it, so maybe just
   stub it all out?


I'm planning on doing the HttpTaskAyncHandler next which will probably take
me a couple of evenings this week.  However, if someone thinks that they
could do it without extensive learning (which is what I'm going to need to
do), then by all means take that on and I'll do some of the others.

I'll let you all know when I get further.
Martin
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] How to create https site with XSP-server?

2014-10-19 Thread Арсен Шнурков
please give any comments to this question:

http://stackoverflow.com/questions/26450340/please-explain-how-to-work-with-tls-in-the-xsp-server

thanks.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] DllImport on Mac

2014-10-19 Thread Brandon Perry
I have a set of C# bindings I have written for the ClamAV project which
work on Windows and Linux by simply DllImport(clamav).

On mac, libclamav.6.dylib gets installed into
/usr/lib/x86_64/libclamav.6.dylib

I cannot for the life of my figure out how to reference this library on mac
for a DllImport. I have tried an absolute path as well as every permutation
of the library name as possible since DllImport will auto detect the
extension.

Any thoughts on referencing a dylib with DllImport? Thanks!

-- 
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] DllImport on Mac

2014-10-19 Thread Daniel Lo Nigro
DllImport(clamav) should still work. Try running your app with
the MONO_LOG_LEVEL=debug environment variable set and see which paths it's
trying to load the library from:

MONO_LOG_LEVEL=debug mono yourapp.exe

Since your library is 64-bit (as it's in /usr/lib/x86_64/), ensure you are
running a 64-bit version of Mono. You need to either run a 64-bit Mono or
compile a 32-bit version of libclamav.

On Sun, Oct 19, 2014 at 5:13 PM, Brandon Perry bperry.volat...@gmail.com
wrote:

 I have a set of C# bindings I have written for the ClamAV project which
 work on Windows and Linux by simply DllImport(clamav).

 On mac, libclamav.6.dylib gets installed into
 /usr/lib/x86_64/libclamav.6.dylib

 I cannot for the life of my figure out how to reference this library on
 mac for a DllImport. I have tried an absolute path as well as every
 permutation of the library name as possible since DllImport will auto
 detect the extension.

 Any thoughts on referencing a dylib with DllImport? Thanks!

 --
 http://volatile-minds.blogspot.com -- blog
 http://www.volatileminds.net -- website

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list