dasBlog Forum Rss Feed

New Post: I get MSDeployPublish error when I try to publish the blog

ttodorov — Thu, 02 May 2013 16:12:51 GMT

I downloaded the source of dasBlog from here, opened it in Visual Studio 2012, compiled it and tried to publish the Web project to IIS. When I get to the "Start Preview" button and click it, I get the following error:

"The target "MSDeployPublish" does not exist in the project."

Can anyone give me a hint what am I doing wrong?

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Mon, 01 Apr 2013 12:49:38 GMT

Hi Scott,

Glad you're interested as well. I'll be sure to post the resolution here, assuming there will be one.

Maybe what really got GoDaddy's attention was the last line of my previous reply:

> If I think of something I’ll be sure to let you know. In the meantime, I’m investigating new hosts.

- Dave

New Post: Live Writer unable to post to dasBlog due to 504

scottmarlowe — Mon, 01 Apr 2013 11:17:58 GMT

Hey guys,

Yeah, I'm still following along and interested if a solution is discovered. I'm surprised you're getting anywhere with GoDaddy. Their initial responses to you were about the same to me as when they swapped out .NET versions from underneath my site then tried to tell me I had programming errors when I hadn't touched anything!

Thanks for doing the legwork and I hope they come up with something.

Scott

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Mon, 01 Apr 2013 00:57:05 GMT

Hi Daniel,

We probably shouldn't eliminate the possibility that ASP.NET has a bug...

Related?
http://support.microsoft.com/kb/925248?wa=wsignin1.0

- Dave

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Mon, 01 Apr 2013 00:52:55 GMT

Hi Daniel,

Good to know, thanks. I'll CC you on my next reply to GoDaddy.

Did you get a chance to try my suggestion yet? Deleting all occurrences of the lowercase word "post" from my last blog post allowed me to submit it (though I only submitted it as a draft since it's still a work-in-progress).

Also, if you can find the time, it would be great if you could repro the problem on your site's root with my custom HTTP handler, just to eliminate the possibility that the problem is a coding/app issue or that I made some kind of embarrassing mistake. If you're interested and you have any questions about how to repro, please let me know - contact me here.

- Dave

New Post: Live Writer unable to post to dasBlog due to 504

DanielMoth — Mon, 01 Apr 2013 00:12:24 GMT

Hi Dave

I don't know about scottmarlowe, but I am actually very interested since the problem still exists for me, so thank you for all the info. Feel free to add my to the email thread with GoDaddy if you think it will help, although you have definitely taken the repro to the next level and I have nothing more to add...

Cheers
Daniel

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Mon, 01 Apr 2013 00:08:05 GMT

Hi everyone,

GoDaddy has bumped it up to their "Advanced Technical Support Team".

Sorry if I've been annoying any dasBloggers that aren't interested in these updates. I'll post again if there's a resolution.

- Dave

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Sat, 30 Mar 2013 15:53:02 GMT

Hi everyone,

GoDaddy's Fourth Reply

Dear Dave,

Thank you for the follow up.

We've reviewed the information you've provided so far, however you had stated you had been using Community Server previously and had no issues with posting to it using Windows Live Writer, and have only experienced issues since you've started using BlogEngine.NET. This would seem to suggest that there is something different between how the two applications handle posting to them that results in one of them working and the other not working.

In order to further troubleshoot this matter, we would need specific instructions for how we can duplicate the issue with POST requests being truncated. We need something we can test so we can experience the issue first-hand. If it's something that can only be duplicated after logging into an application, do not provide us with login credentials, just the instructions as to how to duplicate this.

Please let us know if we can assist you in any other way.

Sincerely,
Joe M.
Online Support

My Response

Hi Joe,

I appreciate your continued interest in helping me to resolve this issue.

> you had stated you had been using Community Server previously and had no issues with posting to it using Windows Live Writer, and have only experienced issues since you've started using BlogEngine.NET

I did not state that to you, but yes I did write that in the discussion to which I had provided a link to you.

The difference in time between my last Community Server post and my first BlogEngine.NET post was quite a while - several months perhaps. Furthermore, I upgraded to 4GH from the standard hosting. So at first I thought it was an application error, just like you, but I’ve come to realize now that there’s evidence to the contrary.

Also note that Daniel Moth, the person whom started that discussion, is also on GoDaddy hosting but he is using an entirely different blog application (dasBlog) and he has experienced the same symptoms as me. Furthermore, he wrote this:

>> For the period in which this started happening (last 2 months) there is nothing out of the ordinary

So it seems that Daniel was using dasBlog continuously when he started experiencing this strange behavior.

Regardless, my comments about Community Server and BlogEngine.NET are old and unrelated to the question that I’ve asked you. As I’ve already shown, I was able to reduce the issue so that it’s not related to any particular application. The code example that I’ve provided to you is not part of any third-party application. It’s a custom HTTP handler that I wrote to test a theory that there was something wrong at the HTTP handler level and it looks like I was proven correct: POST data is being truncated before it reaches custom HTTP handlers in ASP.NET, depending on the presence of the word “post” in the POST body and perhaps other innocuous differences in the data. Also, when POST data is truncated, the response from the server is not received by the client.

No exceptions are thrown. I also suspect that there are no HTTP errors being logged either, but you’d have to check that because I don’t have access to the server logs.

> This would seem to suggest that there is something different between how the two applications handle posting to them that results in one of them working and the other not working.

Yes, it would suggest that, but only if you ignore the code and the screenshots that I’ve already sent to you showing that POST data is being lost or truncated before it’s received by a custom HTTP handler, based on whether the word “post” appears in the POST body or perhaps other innocuous differences in the data, entirely outside of the aforementioned applications. (My custom HTTP handler is configured at my site’s root while my blog software is installed under the /blog/ folder, which is configured as its own application in IIS.)

> In order to further troubleshoot this matter, we would need specific instructions for how we can duplicate the issue with POST requests being truncated.

Ok, I’ve provided troubleshooting steps below.

> If it's something that can only be duplicated after logging into an application, do not provide us with login credentials, just the instructions as to how to duplicate this.

No, it has nothing to do with any third-party application – whatsoever.

Troubleshooting steps:

1 Create a new website in your shared hosting environment on the same server that my site (davesexton.com) is located.
2 Build a .NET assembly named “MetaWebLogWrapper.dll” using the code I provided to you for an HTTP Handler named “TestRequestHandler”. Or you can just copy the MetaWebLogWrapper.dll assembly from the bin folder in my website (I give you permission). Alternatively, the source code and other documents used for the repro appear in the discussion here: http://dasblog.codeplex.com/discussions/284630
3 Configure TestRequestHandler at your site’s root. An example web.config was provided to you or you can grab a copy from http://dasblog.codeplex.com/discussions/284630
This is the important part:
  <system.webServer>
      <handlers>
          <add name="TestHandler_MainSite" verb="*" path="testhandler.axd" type="MetaWebLogWrapper.TestRequestHandler, MetaWebLogWrapper" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode"/>
      </handlers>
  </system.webServer>
4 Follow along with the screenshots that I sent you to reproduce all of the success and failure cases. You can also get a couple of examples from http://dasblog.codeplex.com/discussions/284630
_ _ _ a There is only one GET request but it’s a success case just to show that the handler works. It can be reproduced by simply requesting the handler in a browser.
_ _ _ b POST requests can be sent using Fiddler, as I’ve shown in the screenshots. http://www.fiddler2.com/fiddler2/
_ _ _ c Note that I have not provided the 20K byte examples in their entirety, but these are not necessary to repro the problem.

Please let me know if there’s any additional information that you need.

Thanks,
Dave

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Fri, 29 Mar 2013 12:53:57 GMT

Hi Everyone,

GoDaddy's Third Response

Dear David,

Thank you for taking the time to reply. You have asked multiple questions, and I have attempted to answer them individually below:

Question: What application error? Why do you keep referring to this as an error? The POST data is being truncated. The application is not throwing an exception. Are you seeing something different than me?
Answer: When visiting http://davesexton.com/testhandler.axd?i=1 address, we get the following error-

Received HTTP Handler Request.Reading InputStream property.Content-Length: 0Stream Length: 0CanWrite: FalseIterations: 0Content: Done.

Question: What application vendor? There is no application vendor!
Answer: I apologize if we assumed the site was based on an application or framework not your own.

Question: What other details do you need?
Answer: We can find no issue with server or its ability to process POST requests, and would require that you provide specific evidence that indicates it is a server-side issue before we could investigate further.

Question: What aspect of the hosting may cause POST data to be truncated before it’s received by a custom HTTP handler, but only depending upon particular sequences of bytes and perhaps specific kinds of HTTP headers?
Answer: That is not a hosting or server-related issue.

I have attempted to provide most pertinent information based on the data you provided. If I misunderstood your request, or if any part of my response is unclear, we would appreciate you letting us know. In the meantime, tell us if there is anything else we can do for you.

Regards,

Nathan T.
Online Support Team

My (Probably Final) Response

Hi Nathan,

> When visiting http://davesexton.com/testhandler.axd?i=1 address, we get the following error

That is not an error at all. That is the expected output of my custom HTTP handler. It shows a successful GET request, just like screenshot #3.

The problem is with POST requests. The problem is not with GET requests. I’ve shown this already in my troubleshooting steps, which you asked me to provide with screenshots, though now it seems like you’ve completely ignored them.

Apparently you haven’t even tried to reproduce the actual problem. It’s very discouraging.

> [snip]
> That is not a hosting or server-related issue.

I understand you feel that way. You’ve placed the burden on me to prove otherwise, though I feel that I’ve already done so. I don’t know what else I can provide to prove to you that something strange is happening in your hosting environment that is beyond my control.

If I think of something I’ll be sure to let you know. In the meantime, I’m investigating new hosts.

Thanks for your support,
Dave Sexton

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Thu, 28 Mar 2013 20:31:04 GMT

Hi Everyone,

It appears that the HTTP headers have nothing to do with it. I can reproduce the problem using the same headers that IE sends with a GET request. I haven't mentioned this to GoDaddy, but I don't think that should matter. Right? :)

- Dave

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Thu, 28 Mar 2013 20:14:03 GMT

Hi everyone,

GoDaddy's Second Reply

Dear David,

Thank you for your response. I have reviewed the issue with our Advanced Hosting Support and we could not find any hosting issues that would be causing this. If the Posts were the issue with the hosting, we would have this reported from other customers on the server as this would affect everyone on the server and not you directly. The error we see at http://davesexton.com/testhandler.axd?i=1 is an application error that you're experiencing and not a hosting error. You may want to follow up with the application vendor for additional assistance. If you still feel this is a hosting issue, we will need to know the exact troubleshooting and the specific aspect of the hosting that is causing the issue as we are unable to find any issues with the hosting.

Please let us know if we can assist in any other way.

Regards,

Taylor P.
Online Support Team

My Response

Hi Taylor,

> If the Posts were the issue with the hosting, we would have this reported from other customers on the server as this would affect everyone on the server and not you directly

My impression is that other people have already reported this issue and created support tickets with GoDaddy to try and resolve it. Please refer to the discussion that I linked to in my previous reply.

Furthermore, I don’t think this issue necessarily would affect everyone on the server since it’s related to a specific sequence of bytes in the POST body, not in the format of typical form data and targeting a custom HTTP handler with an .axd extension. Of course, I'm just assuming that the latter two points are required to repro the problem, but my point is that there are several variables here which is possibly why more people aren't reporting it.

> The error we see at http://davesexton.com/testhandler.axd?i=1 is an application error that you're experiencing and not a hosting error.

What application error? Why do you keep referring to this as an error? The POST data is being truncated. The application is not throwing an exception. Are you seeing something different than me?

> You may want to follow up with the application vendor for additional assistance.

What application vendor? There is no application vendor!

My tests use a custom HTTP hander that I wrote specifically to reproduce a particular problem. That’s the only code of which I’m aware that is being executed when the POST request is sent to my ASP.NET server. My custom HTTP handler is configured at the root of my website, which is hosted by GoDaddy 4GH.

I don’t think it gets any simpler than that. I’m not depending upon any third-party software or any code other that my custom HTTP Handler, which I sent to you in its entirety.

> we will need to know the exact troubleshooting

I’ve given you very detailed troubleshooting steps already, it took me over 2 hours to gather screenshots as you requested. But if you feel that it’s not enough, then please tell me what else I can provide. What other details do you need?

> and the specific aspect of the hosting that is causing the issue

Well that’s exactly my question for you. What aspect of the hosting may cause POST data to be truncated before it’s received by a custom HTTP handler, but only depending upon particular sequences of bytes and perhaps specific kinds of HTTP headers?

Thanks,
Dave

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Thu, 28 Mar 2013 14:55:19 GMT

Hi everyone,

Here is my code, configuration and a couple of Fiddler sessions, in case you want to review them to make sure that they aren't the problem. You can also try it yourself on your own website to see if you get the same results as me. Perhaps I should've posted these here before sending them to GoDaddy :P

Custom HTTP Handler

Add this code to a C# project that targets .NET 4.0. Name the assembly MetaWebLogWrapper.dll

using System;
using System.IO;
using System.Text;
using System.Threading;
using System.Web;

namespace MetaWebLogWrapper
{
    public class TestRequestHandler : IHttpHandler
    {
        public bool IsReusable
        {
            get
            {
                return false;
            }
        }

        private void Write(HttpContext context, string value)
        {
            context.Trace.Write(value);
            context.Response.Write(value);
        }

        public void ProcessRequest(HttpContext context)
        {
            Write(context, "Received HTTP Handler Request.");

            try
            {
                Stream input = null;

                if (context.Request.QueryString["i"] == "1")
                {
                    Write(context, "Reading InputStream property.");

                    input = context.Request.InputStream;
                }

                if (input != null)
                {
                    Write(context, "Content-Length: " + context.Request.ContentLength);
                    Write(context, "Stream Length: " + input.Length);
                    Write(context, "CanWrite: " + input.CanWrite);

                    var remainder = context.Request.ContentLength;
                    var buffer = new byte[remainder];
                    var reader = new BinaryReader(input);
                    var n = 0;

                    for (; remainder > 0; n++)
                    {
                        remainder -= reader.Read(buffer, buffer.Length - remainder, remainder);

                        Thread.Sleep(TimeSpan.FromSeconds(.2));

                        if (n == 10)
                        {
                            break;
                        }
                    }

                    Write(context, "Iterations: " + n);
                    Write(context, "Content: " + Encoding.UTF8.GetString(buffer));
                }
            }
            catch (Exception ex)
            {
                Write(context, "Failed: " + Environment.NewLine + ex.ToString());
            }

            Write(context, "Done.");
        }
    }
}

web.config

<?xml version="1.0"?>
<configuration>
    <system.web>
        <httpRuntime requestValidationMode="2.0" />

        <trace enabled="true" localOnly="false" traceMode="SortByTime" pageOutput="false" mostRecent="true" requestLimit="50" writeToDiagnosticsTrace="false" />

        <authentication mode="Forms">
            <forms name=".CommunityServer" protection="All" timeout="60000" loginUrl="~/LoginPage.aspx" slidingExpiration="true" />
        </authentication>
 
        <compilation debug="false">
            <assemblies>
                <add assembly="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
                <add assembly="System.Configuration.Install, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
                <add assembly="System.Transactions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
                <add assembly="System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
            </assemblies>
        </compilation>
    </system.web>

  <system.webServer>
    <modules>
    </modules>
    <handlers>
        <add name="TestHandler_MainSite" verb="*" path="testhandler.axd" type="MetaWebLogWrapper.TestRequestHandler, MetaWebLogWrapper" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode"/>
    </handlers>
  </system.webServer>

</configuration>

Failing POST Request (Fiddler Session)

Don't forget to change the HOST.
Note the trailing newline character (0x0A) after the body.

POST /testhandler.axd?i=1 HTTP/1.1
Accept: */*
Accept-Language: en-US, en, *
User-Agent: Mozilla/4.0 (compatible; MSIE 9.10; Windows NT 6.2; Windows Live Writer 1.0)
Content-Type: text/xml;charset=utf-8
Host: davesexton.com
Content-Length: 8
Connection: Close

post ;.

Failed POST Response

HTTP/1.1 504 Fiddler - Receive Failure
Content-Type: text/html; charset=UTF-8
Connection: close
Timestamp: 13:31:45.189

[Fiddler] ReadResponse() failed: The server did not return a response for this request.

Failed POST Trace

Received HTTP Handler Request.
Reading InputStream property.
Content-Length: 8 
Stream Length: 0 
CanWrite: False 
Iterations: 10 
Content:  
Done.

Successful POST Request (Fiddler Session)

Don't forget to change the HOST.

POST /testhandler.axd?i=1 HTTP/1.1
Accept: */*
Accept-Language: en-US, en, *
User-Agent: Mozilla/4.0 (compatible; MSIE 9.10; Windows NT 6.2; Windows Live Writer 1.0)
Content-Type: text/xml;charset=utf-8
Host: davesexton.com
Content-Length: 8
Connection: Close

lost ;.

Successful POST Response

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 27 Mar 2013 17:34:05 GMT
Connection: close
Content-Length: 142

Received HTTP Handler Request.Reading InputStream property.Content-Length: 8Stream Length: 8CanWrite: FalseIterations: 1Content: lost ;.
Done.

Successful POST Trace

Received HTTP Handler Request.   
Reading InputStream property. 
Content-Length: 8 
Stream Length: 8 
CanWrite: False 
Iterations: 1
Content: lost ;.

Done.

- Dave

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Thu, 28 Mar 2013 14:33:54 GMT

Hi everyone,

I've received my first reply from GoDaddy. As you may have expected, it's not helpful. I've appended GoDaddy's reply below. Following that, I've also appended my reply back to them.

- Dave

GoDaddy's First Reply

Dear David,

Thank you for taking the time to reply. We have reviewed your account and could not find any issues with your hosting plan. The type of error you are experiencing is most likely caused by coding or scripting. Because we do not provide coding support, we are unable to determine what specifically in your code may be causing the error. However, the following may be of some assistance in diagnosing the problem:

By default, our Windows hosting accounts display a generic error when applications generate an exception. We display a generic error because the detailed error messages allow a malicious user to obtain sensitive information.

To troubleshoot the error, you can modify your web.config file and specify that a custom error message displays. A custom error message helps you to locate the specific code that is causing the issue.

CAUTION: The code samples we provide below do not constitute a complete web.config file. Do not replace your existing web.config file with the code we provide. Before changing your web.config file, we recommend creating a backup.

Displaying Custom Error Messages / Enabling Detailed Errors on IIS 7

Use the sample code below to display custom error messages on IIS 7:

<configuration>
   <system.webServer>
        <httpErrors errorMode="Detailed" />
        <asp scriptErrorSentToBrowser="true"/>
    </system.webServer>
    <system.web>
        <customErrors mode="Off"/>
        <compilation debug="true"/>
    </system.web>
</configuration>

You may wish to review your code to determine if there are any issues, because it appears that is the most likely cause of the error. You may also wish to enable detailed error messages as a temporary diagnostic measure. The procedure for this will vary, depending on the scripting language being used. We also recommend consulting both the vendor's online documentation, as well as the large number of online forums dedicated to coding and scripting.

If you determine there is no issue with the code itself and believe the issue is server related, please reply with specific evidence of this and we will investigate the matter further.

Please let us know if we can assist you in any other way.

Regards,
Topher R.
Online Support Team

My First Reply

Hi Topher,

Thanks for your reply.

I believe that you are incorrect. This does not appear to be a coding issue or a configuration issue.

Your advice about how to resolve a problem when a website displays a generic error does not apply to my situation. As my tests have shown, there is no error at all. It is a problem with the POST body being truncated depending on its contents. Specifically, the word “post” appears to be a magic string in GoDaddy’s 4GH shared hosting environment when receiving a POST request. The problem appears to be entirely beyond my control.

I believe that I have provided enough information to prove that the problem is not related to coding or configuration. You should be able to reproduce the problem with the information that I’ve provided. If I have not provided enough information for you, then I’d be happy to provide whatever additional information you need.

There are other people interested in this discussion, so I’ve posted your reply on a public forum:

http://dasblog.codeplex.com/discussions/284630

We’d really appreciate it if you would please investigate the problem further.

Thanks,
Dave Sexton

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Thu, 28 Mar 2013 06:21:20 GMT

Hi everyone,

I was able to reproduce the problem in a custom HTTP handler on my web site, with what seems to be the smallest possible repro string, which I've discovered based on Daniel's painstaking work. It's an 8 byte string. It's not valid XML, but that doesn't matter.

post ;.\n

(Note that \n is not literal, it represents a single newline character: 0x0A)

Deleting any one of the bytes fixes the problem. Changing any one of the letters to a different letter also fixes the problem. Changing the semicolon to a colon, for example, does not fix the problem.

In fact, it does seem like GoDaddy is completely at fault. The problem is that, depending on the contents of the POST body, the metaweblog HTTP handler is receiving a truncated POST body. Since the body contains an XML document, and a truncated XML document is an invalid XML document, the blog software can't parse and save our posts. Furthermore, we don't get a detailed response because GoDaddy prematurely disconnects the socket before ASP.NET has even generated a response. ASP.NET may or may not be throwing an error, depending upon how the blog software handles a truncated XML document, though it most likely throws an XmlException.

I can repro success and failure behavior every time with specific POST content in my custom HTTP handler.

It also seems that simply removing every occurrence of the lowercase word "post" from your blog post, or changing any of its letters; e.g., "pdst", causes it to not get truncated, and WLW succeeds.

So apparently "post" is some kind of magic string in GoDaddy hosting land, at least with respect to the HTTP headers that WLW sends.

I've opened a ticket with GoDaddy and provided them a video showing how to repro, as per the suggestion of the support technician on the phone. However, in their email response they stated that they can't download the video due to security policy and that I must take screenshots instead. Another 2 hours later, I've finally finished reproducing the problem and I've sent them an email with screenshots. I'm not going to include the screenshots here, but below is the entire email that I've sent to GoDaddy tech support. If I receive any interesting responses, I'll post them here too.

- Dave

Email to GoDaddy Tech Support on 3/28/2013

I’ve attached the screenshots that you’ve requested to this email. They are named with incrementing numbers, corresponding to the order of the steps I’ve taken to capture them. Details about each screenshot are listed below.

Overview:

It seems that something in GoDaddy’s infrastructure is truncating the body of POST requests before it’s received by HTTP Handlers, though not all requests are truncated. It depends on the actual bytes in the POST body, and perhaps also particular HTTP headers.

If the POST body is a specific sequence of bytes, such as an ASCII encoding of the string “post ;.\n”, where \n is the ASCII newline character (0x0A), then the entire POST body is lost; however, a slightly different sequence of bytes is not truncated at all. For example, changing the first letter from “p” to “l” avoids truncation. Actually, changing or deleting any letter in the word “post” fixes the problem, so it seems that particular string is some kind of “magic” string. Deleting any of the other characters also fixes the problem, though changing them doesn’t. For example, changing the semicolon to a colon does not fix the problem.

In a large POST body, it seems that simply removing every occurrence of the lowercase term “post” allows the server to receive the entire POST body without any truncation. It does not matter whether the term “post” is followed by the same sequence of bytes as the smaller string identified above; if it’s present at all in a large POST body then the entire body is truncated before it reaches ASP.NET.

Furthermore, whenever the POST body is truncated it prevents HTTP handlers from sending a response back to the client. The ASP.NET trace output in my handler proves that it’s executing, but Fiddler shows that no response is received. ASP.NET does not throw or log any exceptions, so it seems that the socket is being prematurely disconnected somewhere between the client and ASP.NET, within GoDaddy’s hosting environment.

I suspect the cause is one of several possibilities within GoDaddy’s infrastructure. For example, a custom ASP.NET shared hosting environment that performs some kind of security analysis on POST data, virus detection software, a proxy server, packet sniffer or other kinds of network monitoring software. Note that I have none of these running on my local computer and I’m connected directly to my cable modem for these tests.

Notes:

All of the following POST requests are reproducible, every time.

Every POST request has exactly the same HTTP Headers as shown in screenshot 4a, except for the Content-Length header, which is automatically assigned by Fiddler to match the length of the specified POST body.

Screenshots:

The complete source code for my custom HTTP handler.

The actual web.config file located at the site root. (Sensitive information has been replaced with “...".)

A successful GET request from the web browser to my custom HTTP handler. Note that the handler’s response is received by the browser.
a. Trace output for the GET request. Note that Content-Length and Stream Length are both 0, as expected, because there was no POST data.

A successful POST request from Fiddler to my custom HTTP handler. Note that the POST body contains only 4 characters. It is the word TEST, shown in the middle pane. The handler’s response is received by Fiddler and shown in the bottom pane.
a. POST headers are shown in the middle pane. Note that Content-Length is set automatically by Fiddler to 4, indicating that the entire POST body is only 4 bytes. All of the POST request examples in this email use the same HTTP headers, except for Content-Length.
b. Trace output for the POST request. Note that Content-Length and Stream Length are both 4, as expected, because the POST body was exactly 4 bytes.

A failed POST request from Fiddler to my custom HTTP handler. Note that the bottom pane shows the server did not response at all.
a. HEX view of the POST body. Note that the entire POST body is only 8 bytes. The POST body is the highlighted portion of the POST, containing the word “post” followed by a single space, then a semicolon, then a period and finally a single newline character. Also note that the word “post” is not part of the HTTP specification, it’s actually part of the body of the POST, similar to how the word TEST in example #5 was in the body of the POST.
b. Trace output for the failing POST request. Note that Content-Length is 8, as expected, but Stream Length is 0. Stream Length should also be 8. Also note that the Trace shows all of the response output from beginning to end, though Fiddler doesn’t receive any response from the server at all.

A successful POST request from Fiddler to my custom HTTP handler. The handler’s response is received by Fiddler and shown in the bottom pane.
a. HEX view of the POST body. Note the only difference is that I’ve replaced the lowercase letter P with the lowercase letter L as the first byte in the POST body. That change is enough to make the POST succeed.
b. Trace output for the POST request. Note that Content-Length and Stream Length are both 8, as expected, because the POST body was exactly 8 bytes. The HTTP Handler received the entire POST body.

A successful POST request from Fiddler to my custom HTTP handler. The handler’s response is received by Fiddler and shown in the bottom pane.
a. HEX view of the POST body. Note the only difference from the failing POST is that this time I’ve simply removed the last byte of the POST body, which was a new line character (0x0A). That change is enough to make the POST succeed.
b. Trace output for the POST request. Note that Content-Length and Stream Length are both 7, as expected, because the POST body was exactly 7 bytes – the same as the failing POST minus the trailing new line character. The HTTP Handler received the entire POST body.

A failed POST request from Fiddler to my custom HTTP handler. Note that the middle pane shows the Content-Length is over 20K bytes. The entire POST body is a valid XML document. Also note that it does in fact contain the word “post” several times, though it’s always followed by a different sequence of bytes than in example #5. Furthermore, the POST body does not end in a new line character.
a. Partial trace output for the failing POST request. Note that Content-Length is 23979, as expected, but Stream Length is only 10220. The POST body was truncated before it was received by the HTTP handler.

A successful POST request from Fiddler to my custom HTTP handler. Note that the middle pane shows the Content-Length is over 20K bytes. The entire POST body is actually identical to the previous request (#8) except that every lowercase “post” has been removed from the POST body.
a. Trace output for the POST request. Note that Content-Length and Stream Length are both 23776, as expected, because the POST body was exactly 23776 bytes. The HTTP Handler received the entire POST body. Also note that the third line of the POST body contains the word “Post” with a capital P, but it no longer contains any “post” with a lowercase P.

Eagerly awaiting your response,
Dave Sexton

New Post: Live Writer unable to post to dasBlog due to 504

davedev — Sat, 16 Feb 2013 19:37:15 GMT

Hi scottmarlowe,

I never solved this problem, sorry. Though the last one or two posts that I made worked on the first try, but I don't know what was different about them. Maybe they don't have a hyperlink with a trailing period :P

Dave

New Post: Live Writer unable to post to dasBlog due to 504

scottmarlowe — Sat, 16 Feb 2013 19:20:53 GMT

Kind of late to the party but this is an issue I run into from time-to-time and I never did figure out how to get around it short of pasting in the content of my blog post into BlogEngine's post editor. Not too difficult, but not ideal, either.

So, I'm also using BlogEngine.NET as indicated and when I attempt to add a new post or edit an existing one, I get the error as reported.

When I saw Daniel's comment:
<p>post <a href="http://www.danielmoth.com/Blog/">Give</a> .</p> It hit me... This was exactly my problem. By adding that space between the closing </a> tag and the '.', everything suddenly works.

I'm also on GoDaddy and using WLW. If I attempt the same operations against my blogengine instance on localhost, no problems at all.

New Post: is this possible? have dasblog within MVC 4

SystemsGotYou — Tue, 29 Jan 2013 09:16:24 GMT

I have a website based on MVC 4. I'd like to have domain.com/videos be a dasblog blog.

Is this possible?

New Post: Server Error in '/' Application

Milindkhadloya — Mon, 14 Jan 2013 22:47:44 GMT

I installed the latest version of the dasBlog using the web deployment tools, it installed successfully and also displaying the front page, but there are some issues like

1. Front page not displaying properly (alignment issue), images are missing?

2. Click on any url on the page throw the below error

Server Error in '/' Application.

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.

Requested URL: /DasBlog/2009/03/11/CongratulationsYouveInstalledDasBlogWithWebDeploy.aspx

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272

New Post: DasBlog with .NET 4.0 and Integrated Pipeline

creatorul — Wed, 14 Nov 2012 14:25:28 GMT

http://creatorul.net/blog/2012/11/14/RunningDasBlogOnASPNET40Hosting.aspx

New Post: Running dasBlog against ASP.NET 4.0

creatorul — Wed, 14 Nov 2012 14:24:43 GMT

Check this: http://creatorul.net/blog/2012/11/14/RunningDasBlogOnASPNET40Hosting.aspx