[Mono-dev] State of aspnetwebstack on mono

Mon Nov 3 22:05:19 UTC 2014

Hi Miguel,

I've also updated the MachineKey.Protect implementation to have the TODO
removed now.

Please can you merge both https://github.com/mono/mono/pull/1363
(Membership) and https://github.com/mono/mono/pull/1349 (MachineKey) when
you're next free.

I'll start another thread about the other outstanding stuff.

Thanks,
Martin

On 3 November 2014 21:48, Martin Thwaites <monoforum at my2cents.co.uk> wrote:

> Hi Miguel,
>
> I've rebased, and also added the reordering of the compilation.  Please
> can you review that before you merge? I've tested it on a fresh clone and
> it works, but I can understand that this would be a delicate process, so
> would prefer it at least gets a glance over.
>
> Thanks again for all you're doing.
>
> https://github.com/mono/mono/pull/1363
>
> Martin
>
> On 2 November 2014 13:51, Miguel de Icaza <miguel at xamarin.com> wrote:
>
>> I don't really have a strong opinion.   Can you teens me the email you
>> want me to look at?
>>
>>
>> On Sunday, November 2, 2014, Martin Thwaites <monoforum at my2cents.co.uk>
>> wrote:
>>
>>> Thanks Miguel,
>>>
>>> I'll remove that and rebase then.  As the test does both protect an
>>> unprotect, should there really be a separate test?
>>>
>>> Martin
>>>
>>> On 2 November 2014 13:09, Miguel de Icaza <miguel at xamarin.com> wrote:
>>>
>>>> Hello Martin,
>>>>
>>>> The TODO should be used to flag to the consumer that something is not
>>>> implemented or half implemented.
>>>>
>>>> But we do not do this for missing items that could be configured out of
>>>> band.  For those, if they matter, we file bug reports.
>>>>
>>>> Miguel
>>>>
>>>> On Sun, Nov 2, 2014 at 4:20 AM, Martin Thwaites <
>>>> monoforum at my2cents.co.uk> wrote:
>>>>
>>>>> Amazing, thanks Miguel, comments inline.
>>>>>
>>>>> On 2 Nov 2014 00:52, "Miguel de Icaza" <miguel at xamarin.com> wrote:
>>>>> >>
>>>>> >>
>>>>> >> PR1349: https://github.com/mono/mono/pull/1349
>>>>> >> This is the machine key work, and needs a small tweak before it can
>>>>> be merged that I will do this week.
>>>>> >
>>>>> >
>>>>> > I believe the TODO can be removed.   Can you do that?  See comments
>>>>> on pull request.
>>>>>
>>>>> I don't believe the TODO can be removed as the Encrypt Decrypt methods
>>>>> don't allow you use custom decryptors (from what I could tell) it's 4.5
>>>>> specific functionality and controlled via the Web.config.
>>>>>
>>>>> Do you want me to expand on the TODO to make it clearer?
>>>>> >
>>>>> >>
>>>>> >> PR1363: https://github.com/mono/mono/pull/1363
>>>>> >> Another of mine with the MembershipPasswordAttribute
>>>>> >
>>>>> >
>>>>> > Do you mind resending this?  It can no longer be auto-merged from
>>>>> the UI.
>>>>>
>>>>> Before I send this, I need to change the build order in the mcs/class
>>>>> makefile, and wanted to run that past you first as it strikes me as
>>>>> something via fragile.  I sent a message to the list a few days about it,
>>>>> could you respond on that and I'll resend?
>>>>> >
>>>>> >>
>>>>> >> PR1365: https://github.com/mono/mono/pull/1365
>>>>> >> This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel
>>>>> has said he'll take a look at it.
>>>>> >
>>>>> >
>>>>> > Manually aded
>>>>> >
>>>>> >>
>>>>> >> PR1370: https://github.com/mono/mono/pull/1370
>>>>> >> Small one implementing a default of the ReadEntityBodyMode
>>>>> >
>>>>> >
>>>>> > Got this one by hand.
>>>>> >
>>>>> >>
>>>>> >> PR1371: https://github.com/mono/mono/pull/1371
>>>>> >> Another small one, implementing the ClientDisconnectedToken
>>>>> >
>>>>> >
>>>>> > And this one automatically.
>>>>> >
>>>>> >>
>>>>> >> PR1372: https://github.com/mono/mono/pull/1372
>>>>> >> A final small one around the GetBuffer* methods in the httprequest.
>>>>> >
>>>>> >
>>>>> > I do not like this one.  Is there a reason we can not implement the
>>>>> required functionality instead?
>>>>> It's not actually required as the default on ReadEntityBodyMode means
>>>>> that all clients of the code should go directly to input stream.  The code
>>>>> here is enough to ensure that calling code works.
>>>>>
>>>>> Looking at various posts about how to used the
>>>>> GetBufferlessInputStream,  it looks like it needs Async reads as well as
>>>>> Synchronous, so it's a little more involved.
>>>>>
>>>>> The only thing that we could potentially do is change the exception to
>>>>> one you get when you try to read it buffered when classic is set.
>>>>> >
>>>>> > Miguel
>>>>> >>
>>>>> >> There is 1 final small piece that either myself of Chris Carroll
>>>>> will get done this week which is around the AppendTrailing slash and
>>>>> lowercaseUrls properties in RouteBase class.  We just need to put the
>>>>> implementation together.
>>>>> >>
>>>>> >> Anyway, after applying all of these, my large WebAPI solution not
>>>>> only compiles, but it also runs!
>>>>> >>
>>>>> >> If you want to checkout what it looks like with all the patches
>>>>> applied, that would be great, I'd love to have some more information on
>>>>> whether it does work.  I'm sure there will still be bugs, but if it works
>>>>> mostly, then bug fixing is easy (famous last words).
>>>>> >>
>>>>> >> https://github.com/martinjt/mono/tree/mvc_allfixes
>>>>> >>
>>>>> >> Thanks for everyone's help.
>>>>> >>
>>>>> >> Martin
>>>>> >>
>>>>> >> On 20 October 2014 20:42, Martin Thwaites <monoforum at my2cents.co.uk>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Hi Miguel,
>>>>> >>>
>>>>> >>> The code that I'm referring to here is that of the aspnetwebstack
>>>>> on codeplex.  That is to say that they are not something where you can
>>>>> remove the code and recompile (unless there as a specific mono
>>>>> implementation which is not ideal).  The goal is to have the compiled dlls
>>>>> that are available on nuget work, without tweaking to a person's
>>>>> application.
>>>>> >>>
>>>>> >>> I'll have a look and see if I can see where it would be used, but
>>>>> still as you've said on one of my pulls, a half done implementation is
>>>>> better than none.
>>>>> >>>
>>>>> >>> Having the application throw a missing method exception should not
>>>>> be the recommended approach when we can add the property and default it to
>>>>> false.
>>>>> >>>
>>>>> >>> Thanks, and please don't think that things won't getting better
>>>>> with my reviews.  I'm learning what you want so I can review better and
>>>>> help reduce the burden on you and your staff.
>>>>> >>>
>>>>> >>> Martin
>>>>> >>>
>>>>> >>> On 20 Oct 2014 20:04, "Miguel de Icaza" <miguel at xamarin.com>
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> As for the properties, although they should do something to the
>>>>> generated urls, simply adding them should surely be a valid pull?  the
>>>>> issue at the moment is that without them, you get an exception even if it
>>>>> should be false.  I actually think that these are used by other classes
>>>>> when generating urls, not the route collection itself, but I don't know for
>>>>> sure.  Considering that adding them is very low risk, can we not just
>>>>> accept the pull and ask for further work.
>>>>> >>>>
>>>>> >>>> Nope, all they do is allow some code to be compiled, and then get
>>>>> the wrong result.
>>>>> >>>>
>>>>> >>>> You might as well remove the dependency of those properties, and
>>>>> see what else breaks on whatever piece of code you are trying to build.
>>>>> >>>>
>>>>> >>>> Miguel
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> Mono-devel-list mailing list
>>>>> >> Mono-devel-list at lists.ximian.com
>>>>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141103/65eb0eb8/attachment.html>