Live Writer unable to post to dasBlog due to 504

Topics: Support Request
Dec 31, 2011 at 2:50 AM

Hi

I am having trouble posting with Live Writer to my GoDaddy-shared-hosted dasBlog blog. It is on ASP.NET 2.0 with classic pipeline. This was working fine until one day it stopped working (I switched to ASP.NET 4.0 and then realized my mistake and switched back to ASP.NET 2.0).

The Live Writer team after examining the Live Writer logs think it is a server configuration issue and I agree since I can repro this on 3 different machines from various access points. The GoDaddy team is sending me generic responses about not being able to help with 3rd party applications,so they are no use.

Fiddler shows that when Live Writer tries to post to my blog with a POST it receives a 504. This is consistent with Live Writer which complains with “Error attempting to connect to blog at: http://www.danielmoth.com/Blog/blogger.aspx The underlying connection was closed: An unexpected error occurred on a receive.”.

That URL is of course reachable fine (also confirmed with fiddler) when I use Live Writer to update the theme, or update the account information, or retrieve posts from my blog. It is only when it is trying to publish a blog post that the error 504 occurs.

Any ideas on what I can check myself or ask GoDaddy to check so I can diagnose what is going on?

Cheers

Daniel

Coordinator
Dec 31, 2011 at 3:50 AM
That's a gateway timeout error [0]... never seen that before. May be that the server doesn't respond to POST verbs?
Can you try writing a console app, which just does a post (or use something like fiddler) and see if that resolves anything?
Paul
On Fri, Dec 30, 2011 at 18:50, DanielMoth <notifications@codeplex.com> wrote:

From: DanielMoth

Hi

I am having trouble posting with Live Writer to my GoDaddy-shared-hosted dasBlog blog. It is on ASP.NET 2.0 with classic pipeline. This was working fine until one day it stopped working (I switched to ASP.NET 4.0 and then realized my mistake and switched back to ASP.NET 2.0).

The Live Writer team after examining the Live Writer logs think it is a server configuration issue and I agree since I can repro this on 3 different machines from various access points. The GoDaddy team is sending me generic responses about not being able to help with 3rd party applications,so they are no use.

Fiddler shows that when Live Writer tries to post to my blog with a POST it receives a 504. This is consistent with Live Writer which complains with “Error attempting to connect to blog at: http://www.danielmoth.com/Blog/blogger.aspx The underlying connection was closed: An unexpected error occurred on a receive.”.

That URL is of course reachable fine (also confirmed with fiddler) when I use Live Writer to update the theme, or update the account information, or retrieve posts from my blog. It is only when it is trying to publish a blog post that the error 504 occurs.

Any ideas on what I can check myself or ask GoDaddy to check so I can diagnose what is going on?

Cheers

Daniel

Read the full discussion online.

To add a post to this discussion, reply to this email (dasBlog@discussions.codeplex.com)

To start a new discussion for this project, email dasBlog@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Dec 31, 2011 at 4:28 AM
Edited Dec 31, 2011 at 5:07 AM

Hi Paul

Thanks for the response. Sorry that I didn't state it more clearly, but the server does respond to POST verbs, that is what I meant with this statement:

"That URL is of course reachable fine (also confirmed with fiddler) when I use Live Writer to update the theme, or update the account information, or retrieve posts from my blog."

Specifically, for the actions above in Live Writer I see sucess with a 200 response for POST requests to blogger.aspx for blogger.getUsersBlogs and for metaWeblog.getRecentPosts and for metaWeblog.getCategories (along many other GET requests).

The only one that fails with a 504 is when I try to publish, where the POST request is metaWeblog.newPost

Also I tried publishing using Word 2010 and it reported “Word cannot publish this post” and fiddler showed that it choked at the same place in the same way (504 for the POST to metaWeblog.newPost). Interestingly, according to fiddler, Word then issued and OPTIONS command on blogger.aspx which came back OK (200) and included this: Allow: OPTIONS, TRACE, GET, HEAD, POST. So I think it is safe to say that POST is supported.

Any other ideas?

Cheers

Daniel

Coordinator
Dec 31, 2011 at 4:41 AM
What's in the /logs folder?

--
Scott Hanselman - Tiny keyboard, tiny email - Sent from some kind of phone

On Dec 30, 2011, at 8:29 PM, "DanielMoth" <notifications@codeplex.com> wrote:

From: DanielMoth

Hi Paul

Thanks for the response. Sorry that I didn't state it more clearly, but the server does respond to POST verbs, that is what I meant with this statement:

"That URL is of course reachable fine (also confirmed with fiddler) when I use Live Writer to update the theme, or update the account information, or retrieve posts from my blog."

Specifically, for the actions above in Live Writer I see sucess with a 200 response for POST requests to blogger.aspx for blogger.getUsersBlogs and for metaWeblog.getRecentPosts and for metaWeblog.getCategories (along many other GET requests).

The only one that fails with a 504 is when I try to publish, where the POST request is metaWeblog.newPost

Any other ideas?

Cheers

Daniel

Dec 31, 2011 at 6:05 AM

Hi Scott

Thanks for the idea. I usually browse the logs through the admin interface and the Acitvity page (in particular the events looking for Errors - anything with a none-white background). Is that what you mean?

When the actual publishing fails, there is nothing in the logs (beyond the security audit success).

For the period in which this started happening (last 2 months) there is nothing out of the ordinary, I just checked again to be sure. "Ordinary" for my setup are occasional error entries for SMTP exceptions, error executing macro, potentially dangerous request, Validation of viewstate MAC failed, and that's about it.

What else should I look for?

Cheers

Daniel


Coordinator
Dec 31, 2011 at 6:17 AM
Did they recently install URLSCAN? What's in those logs?

--
Scott Hanselman - Tiny keyboard, tiny email - Sent from some kind of phone

On Dec 30, 2011, at 10:06 PM, "DanielMoth" <notifications@codeplex.com> wrote:

From: DanielMoth

Hi Scott

Thanks for the idea. I usually browse the logs through the admin interface and the Acitvity page (in particular the events looking for Errors - anything with a none-white background). Is that what you mean?

When the actual publishing fails, there is nothing in the logs (beyond the security audit success).

For the period in which this started happening (last 2 months) there is nothing out of the ordinary, I just checked again to be sure. "Ordinary" for my setup are occasional error entries for SMTP exceptions, error executing macro, potentially dangerous request, Validation of viewstate MAC failed, and that's about it.

What else should I look for?

Cheers

Daniel


Dec 31, 2011 at 6:30 AM

Thanks Scott.

I can ask GoDaddy the URLSCAN question (this is shared hosting). If they say "no", I guess that is the end of that path. If they say "yes" what is the next step? [just thinking ahead]

The logs (in terms of errors) have the 4 type of messages I listed in my earlier response. Sorry, where/what specificaly are you suggesting I do with the logs beyond what I described?

Cheers

Daniel

Coordinator
Dec 31, 2011 at 6:36 AM
If there is not log, it's likely there is something about either the path or the post that some new module upstream doesn't like. Can I see you web.config?

Also, consider a better hoster.

--
Scott Hanselman - Tiny keyboard, tiny email - Sent from some kind of phone

On Dec 30, 2011, at 10:30 PM, "DanielMoth" <notifications@codeplex.com> wrote:

From: DanielMoth

Thanks Scott.

I can ask GoDaddy the URLSCAN question (this is shared hosting). If they say "no", I guess that is the end of that path. If they say "yes" what is the next step? [just thinking ahead]

The logs (in terms of errors) have the 4 type of messages I listed in my earlier response. Sorry, where/what specificaly are you suggesting I do with the logs beyond what I described?

Cheers

Daniel

Dec 31, 2011 at 6:49 AM

Yes, you are right, a better hoster is what I'll do once my deal expires.

Also FYI, I tried editing an existing post with Live Writer and that also works fine. So that is two more succesful POST commands to blogger.aspx, namely metaWeblog.editPost and metaWeblog.getPost .

Also I should share that posting through the web interface also works fine. It is just the metaWeblog.newPost that seems to be the problem.

Anyway, web.config sent to you offline, thanks for looking at it Scott!

Cheers

Daniel

Dec 31, 2011 at 10:58 AM

Having spent more time on this, I still don’t have a solution, but I have more data that narrows down the problem.

It appears that when posting through Windows Live Writer (WLW) some posts will go through and others won’t, based on the content of the blog post body! The posts that can’t make it through with metaWeblog.newPost or metaWeblog.editPost (and result in the 504) can be posted fine through the blog interface. In fact, once posted, you can retrieve them fine in WLW, but trying to re-post them again through WLW (with no changes) results in the same error.

Example of a blog entry that fails with WLW (but not through blog interface):

<p>post <a href="http://www.danielmoth.com/Blog/">Give</a>.</p>

Example of 4 separate blog entries that each succeeds with WLW (note the very minor tweaks compared to the one above):

<p>post <a href="http://www.danielmoth.com/Blog/">Give</a> .</p>

<p>post <a href="http://www.danielmoth.com/Blog/">Give</a></p>

<p>pist <a href="http://www.danielmoth.com/Blog/">Give</a>.</p>

<p>lost <a href="http://www.danielmoth.com/Blog/">Give</a>.</p>

Surprise: While each one of the 4 HTML fragments succeeds on its own, if I put them altogether then the post fails again.

The above is just one example that I painstakingly narrowed down and reproduced. I have other posts that are failing where the “rule” above is not helping me work around the issue.

Questions:

  1. What is the difference between WLW (i.e. blogger.aspx methods) and the web posting interface that can cause such behavior? One would expect them to be identical.
  2. Regardless of whether the web interface is not strict enough or WLW is too aggressive, how do I make WLW behave like the web interface?
  3. Or at least how can I get WLW to tell me exactly what element/line_column it doesn’t like so I don’t have to go through this trial and error? It is near impossible to narrow down what is causing it to fail each time.
  4. What changed on the web server to cause this issue with blogger.apsx methods becoming stricter?

In case you are wondering how the first snippet above that fails looks like in fiddler, here is the relevant fragment:

<member>

<name>description</name>

<value>

<string>&lt;p&gt;post &lt;a href="http://www.danielmoth.com/Blog/"&gt;Give&lt;/a&gt;.&lt;/p&gt;</string>

</value>

</member>

Any clues?

Cheers

Daniel

Jan 4, 2012 at 8:31 PM
shanselman wrote:
Did they recently install URLSCAN?




As expected, GoDaddy support responded to my specific question about URLSCAN with this:

"We cannot advise on exact updates made to a shared hosting server for security reasons. If you are receiving an error, please respond to this email with a screen shot of the error and any steps to duplicate."

Coordinator
Jan 7, 2012 at 5:59 AM
No idea. It's not DasBlog. Why not move hosts?

--
Scott Hanselman

On Dec 31, 2011, at 2:59 AM, "DanielMoth" <notifications@codeplex.com> wrote:

From: DanielMoth

Having spent more time on this, I still don’t have a solution, but I have more data that narrows down the problem.

It appears that when posting through Windows Live Writer (WLW) some posts will go through and others won’t, based on the content of the blog post body! The posts that can’t make it through with metaWeblog.newPost or metaWeblog.editPost (and result in the 504) can be posted fine through the blog interface. In fact, once posted, you can retrieve them fine in WLW, but trying to re-post them again through WLW (with no changes) results in the same error.

Example of a blog entry that fails with WLW (but not through blog interface):

post http://www.danielmoth.com/Blog/">Give.

Example of 4 separate blog entries that each succeeds with WLW (note the very minor tweaks compared to the one above):

post http://www.danielmoth.com/Blog/">Give .

post http://www.danielmoth.com/Blog/">Give

pist http://www.danielmoth.com/Blog/">Give.

lost http://www.danielmoth.com/Blog/">Give.

Surprise: While each one of the 4 HTML fragments succeeds on its own, if I put them altogether then the post fails again.

The above is just one example that I painstakingly narrowed down and reproduced. I have other posts that are failing where the “rule” above is not helping me work around the issue.

Questions:

  1. What is the difference between WLW (i.e. blogger.aspx methods) and the web posting interface that can cause such behavior? One would expect them to be identical.
  2. Regardless of whether the web interface is not strict enough or WLW is too aggressive, how do I make WLW behave like the web interface?
  3. Or at least how can I get WLW to tell me exactly what element/line_column it doesn’t like so I don’t have to go through this trial and error? It is near impossible to narrow down what is causing it to fail each time.
  4. What changed on the web server to cause this issue with blogger.apsx methods becoming stricter?

In case you are wondering how the first snippet above that fails looks like in fiddler, here is the relevant fragment:

<member>

<name>description</name>

<value>

<string>

post http://www.danielmoth.com/Blog/">Give.

</string>

</value>

</member>

Any clues?

Cheers

Daniel

Jan 9, 2012 at 1:03 PM

Scott, from your conclusion that "it is not dasblog", does that mean you looked at the webconfig file I sent and saw no issues? How do you suggest debugging this issue given the detailed repro steps I provided?

I have already paid this host until 2013, so I am hesitant to move hosts until I have exhausted diagnosing the issue with this host.

Cheers

Daniel

Apr 25, 2012 at 4:43 PM

Hi,

I'm sorry to bring up an old thread from a completely different project, but I'm running into the same exact issue trying to submit my first post to my new BlogEngine.NET blog and I can't figure out why.  I've been using Community Server for years without any issue posting via WLW, but now that I'm using BlogEngine.NET I can't post at all.

This thread is the only one I've seen that seems to address the exact problem that I'm having.  I'm also using GoDaddy shared hosting (4GH, to be exact) and the latest version of WLW.

Did you ever solve the problem?  I hope the solution wasn't to switch hosts :)

In one respect, the root of the problem does seem to be specifically with GoDaddy.  For example, I just ran fiddler and got a 504 error when publishing my new post in WLW.  So I copied the failed session in Fiddler and created a new POST request based on it.  I changed the host to my local computer and ran my blog locally via IIS Express.  Then I tried replaying the request in Fiddler to my localhost and it worked without any errors!  I didn't change the blog content at all.

However, in another respect it doesn't seem like a GoDaddy issue.  My blog has an image, and I noticed that even after failing to upload in WLW with a 504 error, the image was successfully uploaded to the correct folder.  I'm not using the FTP setting - I'm using the blog setting for uploading pictures.  I didn't have Fiddler running at the time though, so it's possible that WLW issue a separate request that didn't fail and then for subsequent attempts didn't try re-uploading the image because it knows it's already on the server?

Does anybody know whether BlogEngint.NET and dasBlog use the same metaweblog API?  If so, then I'd bet that the host has nothing to do with the problem and it's either a bug in WLW or the metaweblog API.

Thanks in advance for any advice,
Dave

Apr 25, 2012 at 4:49 PM

Hi Dave

Sounds similar, I also had some images succeed while the overall post failed.

I have not solved it. Some of my posts succeed; for the ones that don’t I take the html from livewriter and post them manually from the dasBlog web interface… too much effort, but I have cut down on blogging on my own blog (use a team blog instead), so not the end fo the world for me now.

If you find a real solution, please let me know.

Cheers

Daniel

Apr 25, 2012 at 4:55 PM

I'll certainly let you know if I figure it out.  Thanks for responding.

- Dave

Feb 16, 2013 at 7:20 PM
Edited Feb 16, 2013 at 7:48 PM
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.

Just thought I'd throw some observations out for the next person to come along.
Feb 16, 2013 at 7:37 PM
Edited Feb 16, 2013 at 7:49 PM
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
Mar 28, 2013 at 7:21 AM
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:
  1. The complete source code for my custom HTTP handler.
  2. The actual web.config file located at the site root. (Sensitive information has been replaced with “...".)
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
Mar 28, 2013 at 3:33 PM
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
Mar 28, 2013 at 3:55 PM
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
Mar 28, 2013 at 9:14 PM
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
Mar 28, 2013 at 9:31 PM
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
Mar 29, 2013 at 1:53 PM
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
Mar 30, 2013 at 4:53 PM
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
Apr 1, 2013 at 1:08 AM
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
Apr 1, 2013 at 1:12 AM
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
Apr 1, 2013 at 1:52 AM
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
Apr 1, 2013 at 1:57 AM
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
Apr 1, 2013 at 12:17 PM
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
Apr 1, 2013 at 1:49 PM
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