GitHub user masaori335 opened a pull request:
https://github.com/apache/trafficserver/pull/264
TS-3810: Add error handling when stream is CLOSED
https://issues.apache.org/jira/browse/TS-3801
You can merge this pull request into a Git repository by running:
$ git pull https://gi
GitHub user maskit opened a pull request:
https://github.com/apache/trafficserver/pull/263
TS-3799: Fix handling of padding in DATA frames
Traffic Server doesn't handle padded DATA frames correctly, and returns
GOAWAY frame with PROTOCOL_ERROR.
https://issues.apache.org/jira/bro
Github user SolidWallOfCode closed the pull request at:
https://github.com/apache/trafficserver/pull/260
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Wow, that's a serious alignment requirement in frame 3. It's a big change from
frame 4.
On Friday, July 24, 2015 5:26 PM, Nick Kew wrote:
The stream-editor plugin was developed and tested against TS 5.2.x.
Against trunk, it builds just fine, but I've only just tried to run it,
and
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125255226
As long as it's a WARNING (and doesn't block TS from coming up), I'm fine
with that as well.
OTOH if a crash/abort is involved, it sounds like a compatib
Hi all,
I know I’m sounding like a broken record, but, we’re not getting this right.
So, please, read this:
1) Now that we don’t maintain a CHANGES file, anything but the most trivial
changes (comments, formatting and docs) *must* have Jira associated with it.
This is the only way the RM will
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125252893
That seems reasonable, and WARNing on an empty file also seems reasonable.
Crashing, less so.
---
If your project is set up for it, you can reply to this email an
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125252626
Perhaps what we should do is allow the configuration to specify the empty
string for revolv.conf to mean "don't use resolv.conf". I think it's reasonable
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125251374
Nothing? Use the resolvers in ```records.config```? Assume every name is in
```/etc/hosts```? Never use DNS names?
---
If your project is set up for it, you can r
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125251555
@bgaff : Also, pls see my comment above - we do have some use cases, where
there's no origin communication involved.
---
If your project is set up for it, you c
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125250884
@jpeach , what are you supposed to do without any resolvers?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125250513
I'm not sure that always falling back to a default is desirable. If the
operator specified an empty ```resolv.conf```, then why wouldn't we use what
they configure
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125249706
@bgaff : How does this work when I have a set up that terminates all
connections locally (i.e. no origins to talk to)? We do have some use cases (w/
and w/o inte
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/262#issuecomment-125246959
Looks fine to me.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
14 matches
Mail list logo
