Searching \ for '[ADMIN]: URLs being stripped from PICList.com arch' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: ': URLs being stripped from PICList.com arch'.

Exact match. Not showing close matches.
PICList Thread
'[ADMIN]: URLs being stripped from PICList.com arch'
2005\08\04@074248 by Philip Pemberton

face picon face
Hi,
 I just pulled up Ruben Jonsson's message regarding RoHS in the PIClist.com
archive and no matter how many times I refresh it, I can't get the URLs to
appear. The copy of the message I've got here, OTOH, contains two links to
the DTI website.
 It looks like the PIClist.com archive isn't picking up angle-bracketed
URLs as URLs, so they end up getting output as HTML tags. For instance:
 <http://www.google.com/> is invisible (look at the page source)
 http://www.google.com/ turns into a link

 Any chance of getting this fixed? At the very least, the archive should be
converting < and > characters into their HTML equivalents (&lt; and &gt;)...
It might also be doing the same thing with "" type quotes (should be &quot;).

Thanks.
--
Phil.                              | Acorn RiscPC600 SA220 64MB+6GB 100baseT
spam_OUTphilpemTakeThisOuTspamphilpem.me.uk              | Athlon64 3200+ A8VDeluxe R2 512MB+100GB
http://www.philpem.me.uk/          | Sony MZ-N710 NetMD Minidisc
... Damnit Jim, I'm a doctor not a Tagline

2005\08\04@094204 by Howard Winter

face
flavicon
picon face
Phil,

On Thu, 04 Aug 2005 12:39:45 +0100, Philip Pemberton wrote:

> Hi,
>   I just pulled up Ruben Jonsson's message regarding RoHS in the PIClist.com
> archive and no matter how many times I refresh it, I can't get the URLs to
> appear. The copy of the message I've got here, OTOH, contains two links to
> the DTI website.
>   It looks like the PIClist.com archive isn't picking up angle-bracketed
> URLs as URLs, so they end up getting output as HTML tags. For instance:
>   <http://www.google.com/> is invisible (look at the page source)
>   http://www.google.com/ turns into a link

I think this must be email-client dependant.  This all looks OK here - although my email software doesn't make
links as such (it handles them as such when you highlight them) the part before "is invisible" is the URL in
pointy brackets, the one below is just the text of the URL.

Cheers,


Howard Winter
St.Albans, Herts


2005\08\04@095618 by Alan B. Pearce

face picon face
>>   <http://www.google.com/> is invisible (look at the page source)
>>   http://www.google.com/ turns into a link
>
>I think this must be email-client dependant.  This all looks OK
>here - although my email software doesn't make links as such
>(it handles them as such when you highlight them) the part
>before "is invisible" is the URL in pointy brackets, the one
>below is just the text of the URL.

No it is not in email, it is on the piclist.com website that he finds the
links dropped.

2005\08\04@171438 by James Newton, Host

face picon face
Fixed. Thanks for letting me know.

---
James.



{Quote hidden}

> -

2005\08\04@172527 by James Newton, Host

face picon face
And were is that logic analyzer from an SX and a cell phone LCD project,
Phil?

Huh? Huh? <grin>

I fixed the archive, now you have to publish the PCB...

Just kidding...

---
James Newton: PICList webmaster/Admin
jamesnewtonspamspam_OUTpiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



> {Original Message removed}

2005\08\04@185537 by Hector Martin

flavicon
face
Hi James :)

Just in case you didn't see it, I answered the piclist access
troubleshooting thread with some info. It seems we might be getting
down to the root of the problem...

BTW, piclist.com access for me has been quite sluggish, sometimes I
tried piclist.com and it wouldn't load, but then I'd try quickstepper
and it would load (slowly), then piclist.com would load fine. But I've
never had this problem before, so I doubt it is related to the other
troubles (unless my ISP touched something).
--
Hector Martin (@spam@hectorKILLspamspammarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2005\08\04@192904 by James Newtons Massmind

face picon face
Hang in there... I'm still trying to figure out what to do.

Again, it is not, can not be, exclusively something that piclist.com is
doing wrong. At worst, piclist.com is not willing to negotiate to a smaller
packet size than 1500. But that is a perfectly valid size for a packet and
should not be dropped by any node between here and there (as far as I can
see, I have been known to be wrong before) and so must be the "fault" of the
ISP or some node between me and you.

It can NOT be piclist.com's "fault" because lots of other people can see the
site just fine, reliably, quickly, and without fail. And EVERYONE can see
the site via anonymizer or any of the other web proxy services.

I have a linksys router on the front end of the server and it does not have
much in the way of settings for MTU related issues. The only one is
"automatic / manual MTU size" and if manual, then what size MTU. Currently,
it is on automatic and it has been like that for years. So if there is a
problem, it must be a bug in the linksys or some bug between the linksys and
the NT 4 / IIS 4 server. So far, I can't find any mention of such a bug
related to the linksys model I have on the internet or at the linksys site.
However they do have a firmware update which I will apply as soon as I can
make sure I have another unit ready to drop in if this one doesn't survive
the firmware load.

---
James.



> {Original Message removed}

2005\08\04@195540 by Hector Martin

flavicon
face
James Newtons Massmind wrote:
> Hang in there... I'm still trying to figure out what to do.
>
> Again, it is not, can not be, exclusively something that piclist.com is
> doing wrong. At worst, piclist.com is not willing to negotiate to a smaller
> packet size than 1500. But that is a perfectly valid size for a packet and
> should not be dropped by any node between here and there (as far as I can
> see, I have been known to be wrong before) and so must be the "fault" of the
> ISP or some node between me and you.

But the MTU limits the packet size. 1500 is just about the maximum
packet size possible (it's the physical limit for ethernet). Any node
between with a lower MTU will drop your packets, since they use DF,
and that is the proper behavior (there are links with MTUs of 600 or
less, and it is perfectly acceptable, although not optimal). Your
packets use DF because your server is attempting to do PMTU discovery,
so that hopefully dropped packets will be reported back and your
server will adjust the packet size. But if it doesn't work right,
you'll just kill all your packets.

>
> It can NOT be piclist.com's "fault" because lots of other people can see the
> site just fine, reliably, quickly, and without fail. And EVERYONE can see
> the site via anonymizer or any of the other web proxy services.

Anyone with a 1500 MTU through all the path will always see your site.
But if your server is configured wrong, or your router, or something
at your end is breaking PMTU discovery, packets can get dropped
forever at places where the MTU is lower. I think it is not strange
for most people to have a 1500 path MTU, since it is the most optimal,
but some people might have smaller limits. And those might be broken.
Via anonymizer the connection is pretty much rewritten, since
everything goes out and back into the TCP stack at application level,
so if the anonymizer is configured properly and does PMTU properly,
and has a 1500 MTU path to your server, it will work for everyone.

{Quote hidden}

If the problem is on your side, it is definitely a bug or big
misconfiguration. A question: is your server under a publicly routable
IP address directly, or does the router use a forwarding feature to
forward port 80 to the server? That might have something to do with it.

A quick test should be to turn off PMTU discovery and let NT4 unset
the DF bit. This is sub-optimal since it will cause packet
fragmentation for paths with a smaller MTU, but it will not cause any
additional load for your connection (since the packets get fragmented
at the router with a smaller MTU), and it might be an acceptable
long-term solution if nothing else fixes the problem. The site might
be 20% slower for those under lower-MTU connections, but I guess
that's better than not being able to access it at all.
--
Hector Martin (KILLspamhectorKILLspamspammarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2005\08\04@204914 by James Newton, Host

face picon face

Hector Martin says:
> Anyone with a 1500 MTU through all the path will always see your site.
> But if your server is configured wrong, or your router, or
> something at your end is breaking PMTU discovery, packets can
> get dropped forever at places where the MTU is lower. I think
> it is not strange for most people to have a 1500 path MTU,
> since it is the most optimal, but some people might have
> smaller limits. And those might be broken.
> Via anonymizer the connection is pretty much rewritten, since
> everything goes out and back into the TCP stack at
> application level, so if the anonymizer is configured
> properly and does PMTU properly, and has a 1500 MTU path to
> your server, it will work for everyone.

Ok... I can see what you are saying... Lets take that as the best
possibility and troubleshoot it.

{Quote hidden}

I've just completed the router firmware upgrade...

...could I impose on you to check it again? Did that fix the problem?

> If the problem is on your side, it is definitely a bug or big
> misconfiguration. A question: is your server under a publicly
> routable IP address directly, or does the router use a
> forwarding feature to forward port 80 to the server? That
> might have something to do with it.

The router forwards port 80 to the server on the internal network.

> A quick test should be to turn off PMTU discovery and let NT4
> unset the DF bit. This is sub-optimal since it will cause
> packet fragmentation for paths with a smaller MTU, but it
> will not cause any additional load for your connection (since
> the packets get fragmented at the router with a smaller MTU),
> and it might be an acceptable long-term solution if nothing
> else fixes the problem. The site might be 20% slower for
> those under lower-MTU connections, but I guess that's better
> than not being able to access it at all.

I'll try that if the router firmware upgrade doesn't work.

---
James Newton: PICList webmaster/Admin
RemoveMEjamesnewtonTakeThisOuTspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



2005\08\04@231911 by Carey Fisher - NCS

face picon face
James,
Whatever you did fixed my access problem.  I can now get to the PICLIST
website...  HOORAY!!!!!!
Carey

Carey Fisher, Chief Technical Officer
New Communications Solutions, LLC
spamBeGonecareyfisherspamBeGonespamncsradio.com
Toll Free Phone:888-883-5788
Local Phone:770-814-0683
FAX: 888-883-5788
http://www.ncsradio.com


  > {Original Message removed}

2005\08\04@232421 by Hector Martin

flavicon
face
James Newton, Host wrote:
> I've just completed the router firmware upgrade...
>
> ...could I impose on you to check it again? Did that fix the problem?
>

Well, at least now piclist.com is sending me correct (614-byte) sized
packets when I set my MTU to 600. So either I mixed something up the
first time I checked it, or that did indeed fix the problem.

Can you check with someone that previously had problems?


--
Hector Martin (TakeThisOuThectorEraseMEspamspam_OUTmarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2005\08\04@232821 by Hector Martin

flavicon
face
Carey Fisher - NCS wrote:
> James,
> Whatever you did fixed my access problem.  I can now get to the PICLIST
> website...  HOORAY!!!!!!
> Carey
>

So indeed I was right, the problem is now fixed and was caused by the
MTU thingy. Cool!

Hector Martin (RemoveMEhectorspamTakeThisOuTmarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2005\08\05@015738 by James Newton, Host

face picon face
source= http://www.piclist.com/piclist/2005/08/04/232821a.txt?

Hector Martin  says:
> So indeed I was right, the problem is now fixed and was
> caused by the MTU thingy. Cool!

And the MTU thingy was caused by a bug in the router firmware which was
fixed by Linksys late last year in a firmware upgrade that I failed to
notice. And I failed to notice it because they put up a new website (www1.
vs the www. that it used to be) and stopped updating the old website without
takeing it down! (can you see that vein pulsing in my forehead?) So my
bookmark was taking me to a page that never changed.

I did fined in the version notes for the firmware that there was a bug with
"fragmented packets not arriving to destination in correct sequence." There
was also and item that said "When MTU option set disable, default MTU and
server MRU can not work properly" but I had MTU enabled so that shouldn't
have been an issue.

I should appologize for taking so long to find and fix this but... whadda
want for free? *grin*

And I must say, THANK YOU Hector!


---
James Newton: PICList.com webmaster, former Admin #3
jamesnewtonEraseMEspam.....piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...